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1.0 Score 

This oocument is a specification of the on-media structure 
that is used by Files-11, FiVes-11 is a oeneral eurpose 
file structure which is intended to be the standard file 
structure for all medium to large. PDP-11 systems. Small 
systems such as RT-li have been specifically excluded be- 
cause the complexity of Files-11 would impose too qreat a 
buroen on their simplicity and small size. 

This document describes structure level 2 of Files-11, also 
referred to as 00S-2 (on-disk structure 2), It contains 
feature and reliability improvements over structure level 1 

CODS-!) . 



1 . 1 Convent ions 

41 1 numerical values given in this document are in decimal 
radix, unless indicated otherwise. 

Within the file structure are fields containing binary i n- 
teaers of various lengths. Unless otherwise indicated, all 
these fields are in the standard numerical format, which 
means that the most significant bits are stored in .the hi- 
ghest numbered address. 

In the descriptions of various structures on the disk, there 
are fields that are labeled "not used". These fields must 
be zero, so that they can be made non-zero for future use. 
Since they are reserved for future use, programs readina 
these structures should not assume that these fields are in 
fact zero. 



2.0 M edi um 

Files-11 is a st ructure, whi ch is imposed on a medium. That 
medium must have certain properties, which are described in 
the following section. Generally soeakinq, block address- 
able storage devices such as disks and Dectaoe are suitable 
for Files-11; hence Files-11 structured media are oeneri- 
cally referred to as disks. 



2 . 1 Vo 1 ume 

The basic medium that carries a Files-11 structure is re- 
ferred to as a volume, A volume (also often referred to as 
a unit) is defined as an ordered set of logical blocks. a 
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Topical block Is an array of 512 5-bit bytes. The Topical 
blocks In a volume are consecutively numbered from 0 to n- 1 # 
where the volume contains n logical blocks. The number as- 
signed to a logical block is called Its logical block 
number# or LBN • Files-11 Is capable of describing volumes 
ud to 2**32 blocks in size. In practice# a volume shoula be 
at least 10? blocks In size to be useful. 

The logical blocks of a volume must be randomly addressable. 
The volume must also allow transfers of any length uoto 65K 
bvtes# In multiples of four bytes. When a transfer Is 
longer than 512 bytes# consecut i vel y numbered 1 ogi cal blocks 
are transfered until the byte count is satisfied. In other 
words, the volume can be viewed as a partitioned array of 
bvtes. It mgst allow reads and writes of arrays of anv 
length less than feSK bytes# provided that they start on a - 
logical block boundary and that the length Is a multiple of 
four bvtes, when only part of a block Is written# the con- 
tents of the remainder of that logical block will be unde- 
fined. 

The logical blocks of a volume are grouped into clusters. 
The cluster is the basic unit of space allocation on the vo- 
lume, Each cluster contains one or more logical blocks? 
-the number of blocks In a cluster Is known as the volume 
cluster factor# or storage map cluster factor. 

A volume Is identified as a Files -11 volume by the home 
block. The home block Is located at a defined physical lo- 
cation on the volume* and Is identified by the presence of 
checksums and predictable values. The hpme block is des- 
cribed in detail In section 5,1, To Identify the volume# 
the home block contains a volume label# which is a string of 
gp to 12 ASCII characters. The characters are restricted to 
the printing ASCII set (i,e,# excluding control characters 
and rubout). Further# it 1 s reccommended that volume labels 
be restricted to alphanumerics only to avoid conflicts with 
the command languages of supporting systems. The volume 
label of a volume may not tee null. 



2.2 Volume Sets 

A volume set is a collection of related volumes that are 
normally treated as one logical device in the usual ooerat- 
1 no system concent. Each volume contains its own Files-11 
structure? however# files on the various volumes, in a vo- 
lume set may be referenced with a relative volume number# 
which unlguely determines which volume In the set the file 
is located on, 

A volume set Was associated with it a structure name# wMch 
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is an strina of uo to 12 ASCII characters which identifies 
the volume set. The character set limitations of the volume 
label also apply to the structure name. The structure name 
may not be null. 



2,2,1 Tightly Coupled Volume Set - 

A. tightly coupled volume set is a volume set which .is con- 
sistent and self identifying. The volume labels of the vo- 
lumes making up the set must be unioue within the set# and 
must be different from the st ructure name. Relative volume 
one of the set contains a file which lists the volume labels 
of all the volumes in the set# thus associating volume la- 
bels with relative volume numbers. Each volume is identi- 
fied as being part of the set by. carrying the structure 
name# its volume label# and its relative volume number. 



2,2,2 Loosely Couoled Volume Set - 

A loosely coupled volume set is a collection of volumes 
which is not self identifying. There is no file listing the 
volume labels. Only one file may cross from any one volume 
in the set to another, and files in the set which cross vo- 
lumes wav be processed only sequentially. Correct seauene- 
ino of the volumes that hold a particular file is the res- 
ponsibility of the system operator. There are checks that 
will catch most handling errors# but they cannot be *ool- 
oroof. The purpose of the loosely coupled volume set is to 
emulate multi-volume magtape# and allow a file to be read or 
written sequentially with only one volume mounted at a time. 



3,0 Files 

Any data in a volume or volume set that is of any interest 
(i.e.# all blocks not available for allocation) is contained 
in a file, .A file is an ordered set of virtual blocks# 
where a virtual block is an array of 512 8 bit bytes. The 
virtual blocks of. a file are consecutively numbered from 1 
to n, where n is the highest numbered block that has been 
allocated to the file. The number assigned to a virtual 
block is called (obviously) its virtual block number, or 
V8^,. virtual blocks are mapped to unique logical blocks in 
the volume set by Files-11. Virtual blocks may be' processed 
in the" same manner as logical blocks. Any array of bytes 
less than 65 K in length may be read or written, provided 
that the transfer starts on a virtual block boundary and 
that its lemnth is a multiple o* four. 
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For most, ■files# all VBN's less than or eaual to the Highest 
V 3 K i allocated mao to some LBN in the volume set. Such files 
are said to be dense. Files which are sparse contain virtu- 
al blocks which have not been allocated logical blocks. 



3.1 Pile ID 

Each file in a volume set is uniquely identified by a File 
ID, A File ID Is a binary value consisting of 48 bits (3 
PDP-11 words). It is supplied by the file system when the 
file is created# and must be supplied by. the user whenever 
he wishes to reference a particular file. 

The three words of the File ID are used as follows; 

word 1 File Number 

Locates the file within a particular volume of the 
volume set. File numbers ordinarily lie in the 
range 1 through 65535, The set cf file numbers on 
a volume is moderately (but net totally) dense; 
^t any instant in time a file number uniquely 
identifies one file within that volume, 

word 2 File Sequence Number 

Identifies the current use of an individual file 
number on a volume, Fi 1 e..numbers are re-used; 
when a fileis deleted its file number becomes 
available for future use for some other file. 
Each time a file number is re-used# a different 
file sequence number is assignee to distinguish 
the uses of that file number, _ The file seouenee 
number is essential since it is perfectly leqal 
for users to remember and attempt to use a File ID 
long after that file has been deleted, 

word 3 Relative Volume Number 

Identifies which volume of a volume set the file 
is located on. If the volume in question. is not a 
member of a volume set# then this word is zero. 
If the volume is part of a volume set# then the 
relative volume number# or RVN# lies in the range 
from 1 to 65535, In any context where a particu- 
lar volume df a volume set can be identified as 
the "current volume"# such as a file extension 
linkage# a relative volume number of zeno means 
"the current volume", bhen a file is referred to 
in the context of the volume on which it lies# it 
should be referred to with a relative volume 
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number of zero# regardless of the RVN that may be 
assigned to that volume. 

File Number Extension 

If the maximum number of files permitted on the 
volume (as recorded In the home block) Is greater 
than 65535# then the high byte of the relative vo- 
lume number becomes a hlqh order extension to the 
file number. The volume set size Is then limited 
to 255 vol umes# _wh 1 1 e the range of allowable file 
numbers extends from I to 2**24-l, When ?.u bit 
file numbers are used# the file system should not 
create files whose file number Is an Integer mul- 
tiple of 65536 (1.e,» whose low 16 bits are zero). 
Such file numbers will break existing PDP-11 
software (such as FCS-11). 



3.2 File Header 

Each file on a Files-11 volume Is described by a file 
header. The file header Is a block that contains all the 
Information necessary to access the file. It Is not oart of 
the file? rather# It Is contained in the volume's Index 
file, (The index file Is described In section. 5,1). The 
header block is organized Into six areas, of which the first 
five are variable In size.. 



3.2.1 Header A rea - 

\ 

The Information In the header area permits the 
file system to verify that this block Is In fact a 
file header and# In particular# is the header 
being sought by the user. It contal ns., the file 
number and file sequence number of the file# as 
well as Its ownership and protection codes. This 
area. also contains offsets to the other areas of 
the file header# thus defining their size. 



3.2.2 I dent Area - 

The.ident area of a file header contains identifi- 
cation and aceoyntlng data about the file. Stored 
here are the primary name of the file# its crea- 
tion date .and time# revision count# date# and 
time# and expiration date. 
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3.2.3 M ao Area - 

The was? area describes the mapping of virtual 
blocks of the file to the logical blocks of the 
volume. The mapping data consists of a list of 
retrieval pointers. Each retrieval pointer des- 
cribes one group of consecutively numbered logical 
blocks that are allocated to the file. Retrieval 
pointers are arranged in the order of the virtual 
blocks they reoresent. 



3,2. a Access Control List • 

The access control list is an optional area that 
contains a list of users that are allowed access 
to the file. The access control list makes it 
possible .to describe user communities for a par- 
ticular file that cannot be expressed with the 
regular protection classes. 



3.2.5 Reserved Area - 

This optional area is_ reserved for the use by CSS 
or special applications. It will not be used bv 
standard Files-11 systems, ■ 



3.2.6 End Checksum - 

The last two bytes of t he f i 1 e heade r contain a 16 
bit additive checksum of the preceding 255 words 
of the file header. The checksum is used to help 
verify that the block is in fact a file header. 



3,3 Mgiti-header Files 

Since the file header is of fixed, size, it is inevitable 
that fo* some files the mapping information will not fit in 
the allocated soace, A file with a 1 a roe _ amount , c f mapping 
H ata is therefore represented with a chain of file headers. 
Each header maos a consecutive set of virtual blocks: the 
extension linkage in the header area links the headers to- 
gether in order of ascending virtual block numbers. The ex- 
tension pointer in each file header is the File ID of the 
next header in seauence. 
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3.4 V t i - vo 1 ume Files 

Multiple Headers are also needed for files that scan volumes 
in a volume set, A header may only mao logical blocks lo- 
cated on its volumes therefore a multi-volume file js re- 
presented by Headers on all volumes that contain portions of 
that file. In a multi -volume file contained on a loosely 
couded volume set* the File ID of the first header cn each 
continuation volume always has the value 9*9*n* where n is 
the p V n of the volume on whigh.the file starts plus the 
number of preceding volumes containing portions of the file. 



3,5 File Header - Detailed Description 

This section describes in detail the items contained in the 
file header. Each item is identified by a symbol which re- 
presents the offset address of that item within its area in 
the file header. Any item may be located in the file header 
bv locating. the area to which it belongs and then adding the 
value of its of f set _ address • Users who concern themselves 
with the contents of file headers are strongly urged to use 
the offset symbols. The symbol s may be defined in assembly 
1 anauaoe programs by calling and invoking the macro FHDL2S* 
which may be found in the macro library of any system that 
supocrts FiTes-11, Alternatively* one may find the macro in 
the file FliMAC.MAC* which may be obtained from t>*e author. 



3,5,1 v a 1 idity - 

A valid file header is defined by the following rules? 

1, The header checksum is correct* unless SC.CHK is 
set in H,SCHA* in which case the checksum word con- 
tains the value 125252, 

2, The contents of H.IDOF is no less than the offset 
H.FOWN/2. 

3, The four offset bytes are related in the manner 
(H.IDOF) <= (H.MPOF) <= (H.ACOF) <= (H.RSOF). 

4, The high byte of H,FLEV contains the value 2. 

5, The low byte of H.FLEV contains a value greater or 
equal to 1. 

fe. The word H , F MU M contains the file number. 

7, The word H.FSEQ contains the file seouence number. 
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8. The high byte H,FRVN contains the extended part of 
the file number, If any, 

9, The contents of the byte H,USE trust be less than or 
eoual to CH.ACOF) - (H.MPOF). 

a deleted file header conforms to the format of a valid file 
header with the f ol 1 owl ng exceet 1 ons S 

1, SC.MDL is set in H.FCHA, 

2, H.FNUd and H.FPVN contain 2 ero. 

3, The file header checksum' contains zero. 



3.5,2 Header Area Descrlotion - 

The header area of t he f 1 1 e _ header always starts at byte &. 
It contains ' the basic information needed for checking the 
validity of accesses to the file. 



3,5,2. 1 H.IOOF - 1 Byte " Ident Area Offset 

This byte contains the number of 16 bit words 
between the start of the file header and the start 
of the ident area. It defines the location of the 
Ident area and the size of the header area. 



3. 5, 2, 2 H.MPOF - 1 Byte Map Area Offset 

This byte contains the number of 16 bit words 
between the start of the file header and the start 
of the mao area. It defines the location of the 
mao area and, together with H.IDOF, the size of 
the ident area. 



3. 5, 2. 3 H.ACOF - 1 Byte Access Control List Offset 

This byte contains the number of 16 bit words 
between the start of the file header and the start 
of the access control list. It defines the loca- 
tion of the ACL and, together with H. M P0F * the 
size of the mac area. 
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3,5,2. ^ H.RSPF - l Byte Reserved Area Offset 

This byte contains the number of lb bit words 
between the start of the header and the start of 
the reserved area. The reserved area will not be 
used by F i 1 es- 1 1 i t se 1 f # and* may be used by CSS or 
special applications, Together with H.ACQF, this 
byte defines the size of the access control list. 
The size ofthe reserved area is implied by the 
contents of H.RSQF and the end of the header 
block. 

The presence of the ident# map# ACL# and reserved 
areas is optional. Absence of any area is sig- 
nalled not by a zero offset# but bv the eouality 
of the. two offsets that define that area's size. 
All five areas are variable in length? 
i mpl emantat i ons of Files-11 must check the lenath 
of a particular area before attempting to refer- 
ence a .particular entry. 



3, 5. 2, 5 H.FSEG - 2 Bytes Extension Segment Number 

This word contains the value n# where this header 
is the n+lth header of the file? i.e.# headers of 
a file are numbered seauent i a 1 1 v st art 1 nq with 0, 



3, 5, 2. 6- H.FLEV - 2 Bytes Structure Level ana Version 

The file structure level and version is used to 
identify different versions of Files-11 as they 
affect the structure of the file header. This 
permits upwards compatibility of file structures 
as F i 1 es- 1 1 . evo 1 ves# in that the structure level 
word identifies the version of Files-11 that cre- 
ated this particular file, .This document des- 
cribes structure level 2 of Files-11, The high 
■ byte of H.FLEV must contain the value 2, The low 
bvte contains the version number# which must be 
greater or equal to 1, The_ versi on_ number will be 
incremented whenever compatible addi t i ons_are made 
to the Files-11 structure that may be safely ig- 
nored by an old version of the file system. This 
document describes version 1 of structure level 2, 
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3. 5. 2. 7 


H.FNiJM - 2 


Bytes 


File Number 






This word 


contai ns 


the file number of the file 


• 


3. 5. 2. 8 


w.FSEQ - 2 


Bytes 


File Seauenee Number 






This word 


contains 


the file seouence number of 


t he- 




file. 








3. 5. 2. 9 


N.PRVN - 2 


Bytes 


Relative Volume Number 






This, word 


is used 


to hold part of the third 


w o r d 



of the File ID when apcroor i ale. This word is 
usually referred to as the relative volume number, 
when used as such (1,e,« to indicate the volume of 
a volume set)# ft is not recorded in the file 
header# since the RVN of a volume mav change dur- 
ing a file's life# and the RVN portion of a File 
ID may be zero or non-zerp# depending on the con- 
text. However# when the high byte of the RVN is 
used as an extension to the file number# then it 
is recorded in the high byte of this word. The 
low byte of H.FRVN jg always zero.. 



3.5.2.10 H.EFNU - 2 Bytes Extension File Number 

This word contains the file number pf the next se- 
quential extension header for this file. If there 
is no extension header# this word contains 0, 



3.5,2.11 H.EFSQ - 2 Bytes Extension File Sequence Number 

This word contains the file seauenee number of the 
next seauential extension header for this file. 
If there is no extension header# this word . con- 
tai ns 0, 



3.5.2.12 H . E R V N - 2 Bytes Extension Rel at i ve Volume No, 

This word contains the relative volume number of 
the volume in the volume set that contains the 
next sequential extension header for. this file. 
If there is no extension header# or if the exten- 
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sion header is located on the same volume as this 
header# this word contains 8, 



3.5,2.13 H.CIFAT - 32 Bytes User File Attributes 

This area is used by the record manager# or any 
other higher level access mechanism, to store in- 
formation necessary for processing the file# e.o,# 
record control data# end of file mark# etc. 



3.5,2.14 H.FCHA - a Bytes File Character i st i cs 
H.UCHA = H.FC'WA + 0 User Controlled Char, 

H.SCHA = H.FCHA+l System Controlled Char, 

The file character i st i cs words contain the follow- 
ing f 1 aq bits: 



UC.CON 



UC.CNB 



UC.DLK 



UC.RCK 



Set if the file is logically contiguous? 
i,e»# if for all virtual blceks in the 
file# virtual block i maos to looical 
block k+i on one volume for some con- 
stant k. This bit may be implicitly set 
or cleared by file system operations 
that allocate space to the file? the 
user may only clear it explicitly. 

Set if the file is allocated contiguous 
best effort? i.e.# as contiguous as 
possible. 

Set if. the file is oeaccess- 1 ocked. 
This .bit is used as a flag warning that 
the file was not properly closed and may 
contain inconsistent data. Access to 
the file is denied if this bit is set. 

Set if the file. is to be read-checked. 
All read operations on the file# includ- 
ing reads of the file headerCs)# will be 
performed with a read# read-compare to 
assure data integrity. 



UC.WCK Set if the file is to be write-checked. 

All write operations on the file# in- 
cluding modifications of the file 
headerCs)# will be performer witn a 
write# read- compare to assure data in- 
tegri ty. 
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UC.^ID Set if incremental dump (backup) is to 
oe disabled for this file. 

UC.wgc Set if the file .is to be write-back 

cached; i.e.# if a cache is used for 
the file data# data written by a user is 
only written back to the disk when is.it 
removed from the cache. Clear for 
write-thpoudh cache operation. 

The second byte of the file character i st i cs words 

is historically . known as the system controlled 

file characteristics. It contains the, following 

flag bits# defined as referenced within the byte! 

SC.HQL Set if the file is marked for delete. 

If this bit is set# further accesses. to 
the file are denied# and the file will 
be physically deleted when no users are 
accessing it, 

SC. BAD Set if there is a bad data block in the 
file. This bit is as yet uni mpl ementeb. 
It is; intended for dynamic bad block 
handling, 

3C.DIP Set if the file is a directory, 

SC. ACL Set if an access control list exists for 
this file. 

SC.CHK This bit is set if the file header 
checksum was not computed. If this bit 
is set# the checksum wore! must contain 
the octal value 125252. This "feature" 
is for small systems that cannot afford 
the millisecond or two that it takes to 
compute the header checksum; its use is 
strongly discouraged. 



3.5.2.15 - 2 Bytes (not used) 



3.5.2.16 H.USE - 1 Byte Map Words in Use 

. This bvte contains a count of the number of mao 
area words currently in use. 
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3,5,2.17 H . P F I V - l Byte Accessor Privilege Level 

This byte defines the lowest privilege level at 
which an accessor must be running in order to be 
allowed access to the file. Each privilege level 
is a two bit integer) zero refers to the lowest 
privilege and 3 is the highest. Privilege levels 
nay be assigned separately to the basic file ac- 
cess nodes# using the following bit assicnent in 
this bytes 

Read 9its0-l 
Write Bits 2 - 3 
Execute B i t $ 4 - 5 
Delete Bits 6- 7 

An operating system should mae its privilege level 
cgdinq onto this code in the smoothest manner pos- 
sible, For example# the four access modes of VMS, 
user# supervisor# exec#, and kernel# are coded as a 
through 3, respectively, A svstem such as R5X-11M 
which has only two levels (privileged and 
non-pr i v i 1 eged) # should mao the two onto 3 and 0# 
respect i vel y. 

Privilege levels are meant to confine access to 
the contents of files to, suitably t rust wort hy , pro- 
cedures, Thus# a user might be^denied the ability 
to write a record structured file directly Com a 
virtual block, basis') #, but would be permitted to 
write the .file through the record manager# which 
would be suitably privileged. 

For a record structured file# an appropriate set 
of privilege levels would be 0»2#0#0# expressed in 
the order read • write - execute - delete. 



3.5.2,19 H.FQWN - 4 Bytes ' File Owne** UIC 

H.PRQG s H,pO*N+0 Programmer (Member) Number 
H.PROJ a H.FQWN+2 Project (Group) Number 

These words contain the binary user _ i dent i f i cat j on 
code (UIC) of the owner of the file. The file 
owner is usually (but not necessarily) the creator 
of the file. 




—a 
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3.5.2.19 h.fpro - 2 Bytes File Protection Code 

.This word controls what access all users in the 
system may have to the file. Accessors of. a file 
are categorized according to the relatlonshlo 
between the UIC of the accessor and the UIC of the 
owner of the file. Each category Is controlled bv 
a foun bit field In the protection word. The ca- 
tegory of the accessor is selected as follows? 

System B i t s B - 3 

The accessor Is subject to system pro- 
tection If the project number of the UIC 
under which he is running 19 10 octal or 
less. 

Owner Bits 4 - 7 

The accessor is subject to owner protec- 
tion if the UIC under which he is run- 
ning exactly matches the file owner UIC. 

Group B i t s 8 - 1 1 

The accessor is subject to group protec- 
tion If the project number of his UIC 
matches the project number of the file 
owner UIC, 

World Bits 12- 15 

The accessor is subject to world protec- 
tion if he does not fit into any of the 
above categories. 

Four types of access are defined in Files-li? 
read. write. execute, and delete,. Each four bit 
field In the protection word .is bit encoded to 
permit or deny any combination of the four tyoes 
of access. to that category of accessors. Setting 
a bit denies that. type of access to that category. 
The bits are defined, as follows (these values 
apply to a r 1 gh t- J ust 1 f 1 ed protection field!? 

FP.ROV Deny read access 

FP.wpv Deny write access 

FP.EXE Deny execute access 

FP,DEL Deny de 1 et e ■ acces s 

when a user attempts to access a file# protection 
checks are performed in all the categories to 
which he is eligible. In the order system » Owner 
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- group world. The user is granted access to 
the file if any of the categories to which he Is 
eligible grants him access. 

Recommended defaults for file protection for an 
"open shop” svstem are (RWD# RWD# Rw# R] (expressed 
in the order of svstem - owner * group - world# 
where each letter denotes the presence of that 
permission). Observe that only files which con- 
tain executable programs should have execute pro- 
tection turned on. Recommended defaults for a 
"closed shop" system are [RWD#RWD#R# ] , 



3.5, 2. 2’? H.RPRO - 2 Bytes Record Protection Code 

This word controls what access all users in the 
system' may have to ,the^ records in a file. 
Accessors are categorized* into Svstem# Owner, 
Group# and World in the same manner as_for file 
protection. The record protection word is like- 
wise divided into four four bit fields to control 
each accessor category. The four bits in the re- 
cord protection field are defined as follows: 

RP.ROV Deny reading records 

RP.wrv Deny writing new records 

RP.UPD Deny writing existing records 

RP,0El Deny deleting records 

Recommended defaults for record protection for an 
"ooen shop" svstem are (RWUD# Rwuo# RwijD# RJ . 
Recommended defaults for a "closed shop" system 
are [RWUD# RWUD # R # ] . 



3.5.2.21 - ^ Bytes (not used) 



3.5,2,22 H.SF.MK - a Bytes Security Mask 

The security mask is a bit encoded field that re- 
presents information categories that, mav be pre- 
sent "in this file. An accessor also carries a 
security mask that represents information catego- 
ries that he may possess. To read a file# the ac- 
cessor's security mask must be a superset of the 
security mask of the file: to write a file# the 
security mask of the file must be eaual to that of 
the accessor, (Technically# in security mask era* 
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t o c o 1 s * the mask of the file must be a superset of 
that of the writer* but since Files— 11 systems do 
net allow wrltlpg without read permission* both 
conditions aoolv for a writer,) 

Individual bits in the security mask are defined 
system wide by the system manaoer. The installa- 
1 1 on manaoer is responsible for ensuring consis- 
tency and coherency of security masks when volumes 
are used on multiple operating systems, 

Mote that the traditional security level system 
(confidential* secret* etc,) can be achieved by a 
unaey encoding in several bits of the mask. 



3.5,2,23 S.H0HD - 74 Bytes Size of Header Area 

This symbol represents the total size of the 
header area containing all of the above entries. 



3,5.3 Ident Area Description - 

The Ident area of the file header begins at the word Indi- 
cated by H.IDOF, It contains identification and accounting 
data about the file. 



3.5.3. 1 I.FNAM - 23 Bytes File Name 

This area contains the name of the file In ASCII. 
a dot separates name from type* and a semicolon 
separates type from version? both are alwavs pre- 
sent. If the name is shorter than 20 bvtes, it Is 
oadded with blanks? if It is longer. It is t run- 
cated. 



3. 5. 3.2 T.RVNO - 2 Bytes 



Revision Number 



This word contains the revision court of the file 
in binary.. The revision count, Is the number of 
times the file has been accessed for write. 
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3. 5, 3. 3 I.CROT - 8 Bytes Creation Date and Tine 

These eight bytes contain the date and time at 
which the file was created, The time is expressed 
in the standard internal time format, which is a 
fea bit integer representing tenths of microseconds 
elaosed since midnight, 17 November 1858, 



3.5,3,^ I.RVOT - 8 Bytes Revision Date and Time 

The revision time is the time at which the file 
was last deaccessed after being accessed for 
write, Tt is expressed as the same format as the 
creation time above. 



3, 5, 3, 5 I.EXDT - 8 Bytes Expiration Date and Time 

These eight bytes contain the, date and time at 
which the file becomes eligible to be deleted. 
The format is the same as that of the creation and 
revision times above. 



3, 5, 3 , t X.8K0T - 8 Bvtes Backup Date and Time 

These eight_bytes contain the date and time at 
which the file was last backed uo. The format is 
the same as the other dates and times. 



3.5. 3. 7 I.ULAB - 8«? Bvtes User Label 

This optional area contains, any label a. user mav 
wish to associate with the file. 



3.5, 3. 8 S.IDHD « 116 Bvtes size of Ident Area 

This symbol reoresents the size of the ident, area 
containing all of the above entries. 
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3. 5, a an Area Description - 

The rao area of the file header starts at the word indicated 
by H.MPOF. It contains, the information necessary to mao the 
virtual blocks of the file to the logical blocks of the vo- 
lume. This area contains the retrieval oointers that actu- 
ally mao the virtual blocks of the file .to the logical 
blocks of the volume. Each retrieval pointer describes a 
consecutively numbered grouo of logical blocks which is al- 
located to the file. The count field contains the binary 
value n to represent a group of n+i logical blocks. The 
logical block number field contains the logical block number 
of the first logical block in the group. Thus each retriev- 
al pointer maos virtual blocks J through J+n into logical 
blocks k through k + n# respectively# where J is the total 
number olus one of virtual blocks represented. by all creeed- 
ing retrieval pointers in this and all preceding headers of 
the file# n is the value contained in the count field, and k 
is the value contained in the logical block number field. 
Observe that j# k# and n+1 must always be Integer multiples 
of v# the volume cluster factor. 

If the LBN field of a retrieval pointer contains all ones 
(i.e,, points to block 2**22-l or 2**32—15 #, then that retri- 
eval pointer represents an unallocated portion of a sparse 
file. The count field describes the number of unallocated 
virtual blocks in the normal manner. 

There ere four formats of retrieval oointers# identified by 
escape codes. The different formats may be intermixed with- 
in a file header , 

Format i* - two bytes 



I I PI acement I 

1 — 1 - 1 

Retrieval pointer format 0 is. used to store placement data 
in the file header. It describes the placement control sup- 
plied with the allocation that created the following retri- 
eval pointer# allowing the placement of a file to be repli- 
cated when the file is copied or backed uo and restored. 
The coding of the placement data is at present undefined. 
Format 0 is identified by bits 15 and 14 of the first word 
being set to @0 . 
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Format 1 - four bytes. 



1311 High | Count 

| -- ! - - I ------- 

I Lew Order LBN 



Retrieval pointer format 1 provides an 8 bit count field and 
a 22 bit L8N field. It is therefore caeable of representing 
a group of up to 256 blocks on a volume up to 2**22 blocks 
in size. Format 1 is identified by bits 15 and 14 of the 
first word being set to 01, 

Format 2 - si* bytes. 



Count 



LBN 



Retrieval pointer format 2 provides a 14 bit count field and 
a 32 bit LBN field. It is capable of representing a grouo 
of up to 16384 blocks on a volume up to 2**32 blocks in 
size. Format 2 is identified by bits 15 and 14 of the first 
word being set to ID, 

Format 3 - eight bvtes, 

I — I— 

111! High 

I — I - 

I Low Order Count 



!- LBN 

I 



Retrieval pointer format 3 provides a 30 bit count field and 
a 32 bit LBN field. It is capable of describing a, grouo of 
up to 2**30, blocks on a volume up to 2**32 blocks in size, 
Fomat 3 is identified by bits 15 and 14 of the first word 
beimg set to 11. 




1101 

I -- ! 

! 
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3.5.5 Access Control -List - 

The access control list starts at the word indicated by the 
bvte H.ACOF. Note that the entire ACL must be. contained in 
the primary header of the file# and is thus limited. to about 
65 entries. Each access control list entry consists of a 
control word which i dent i f i es t he tvoe of the entry and con- 
tains the access rights given by the list entry,. Fcllowino 
the control word is a value field whose size and interoreta- 
t.ion depends on the type code of the ACL entry. 



RPPO 


\ FPRO | AM |0! 


! T yoe 


m m 


Value 


m m 



The four bit type field controls the size the i nteroretat ion 
of the entry's value field# and to sore extent# the in- 
terpretation of the entry. The tvpe field wav assume one of 
the following values! 



A.UIC 



A.GRO 



A , MEM 



A.PSWD 



A. ACF 



The value field is a 4 bvte UIC. The 
ACL entry is applicable to the accessor 
if the accessor UIC matches the value 
field. 

The value field is a 2 bvte , group 
number. The ACL entry is applicable if 
the group number of the accessor UIC 
matches the value field. 

The value field is a .2 bvte member 
number. The ACL entry is applicable if 
the member number of the accessor UIC 
matches the value field. 

The value field is an 8. byte password# 
hashed by" some algorithm to be deter- 
mined. The ACL entry is applicable if a 
oassword supplied, bv the accessor 
matches the value field (under hashing). 

The value field is the file ID (6 bvtes) 
of an access control file# whose con- 
tents are access control list entries. 
The access rights granted bv this ACL' 
entry are t he . i ntersect i on of the rights 
coded in this entry and the rights 
granted by the entries of the access 
cont ro 1 file. 
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The one bit 0 field, when set, grants ownershio privileges 
(eharae orotection, etc,) 39 oart of the access rights 
granted bv this ACL entry. 

The two bit AM field specifies the least privileged access 
mode permitted to access the file. 

The four bit FPRO f i e 1 d spec 1 f i es the file protection grant- 
ed .. by the ACL entry, if the accessor is eligible. Its con- 
tents are interpreted in the same way as the H.FPRO field of 
the file header. 

The ^our bit RPRO field specifies the record protection 
granted by the ACL entry, if the accessor is eligible,. Its 
contents are interpreted in the same wav as the H.RPRO field 
of the. file header. 

Note that , the access control list augments the permissions 
of the files i , e, , it grants permission rather than res- 
tricting it. This means that ignoring the ACL does not com- 
promise file protection. 



3.5.fe Reserved Area - 

The reserved area of the file header starts at the word in- 
dicates by the byte H,R$0F, This area, is not used by stan- 
dard Files-11 file managers, but is available for use by CSS 
and special aopl i cat i ons. 



3,5.7 End Checksum Description - 

The header check sum occupies the last two bytes of the file 
header. It is verified every time a header is read, and is 
recomputed every time a header is written. If the bit 
SC.CHK is set in the system controlled characteristics word 
H.SCHA, then the checksum has not been computed, and the 
checksum word must contain the octal value 125252. 



3.5.7. 1 H.CKSM - 2 Bytes Block Checksum 

This word is a simple additive checksum of all 
other words in the block. It is computes by the 
following PDP-11 routine or its equivalent? 



MOV Header-address, P0 
CLR R 1 

MOV *255. ,R2 
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1 ?$ : ADD <S0)+#R1 

SOB R2» H$ 
MOV PI, (ROD 



3.6 File Header Layout 

The following is a graohlcal lavoutof the fields In the 
file header. 




Files- 

Heade r 

H . HP OF 
H.RSOF 



H..SCKA 

H.PRIV 
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A re a 



M a p Area Offset | Ident Area Offset 


1 

! 


H, IDOF 


Resv, Area Offset 1 ACL Area Offset 


i 

1 

I 


H..ACQF 


File Segment Number 


i 

1 

i 


H.FSEG 


File St ructure Level 


l 

I 


h.flev 


File Number 


i 

i 

i 


H.FNUM 


File Sequence Number 


* 

i 

! 


H.FSEQ 


Relative Volume Number 


I 

I 

• 


H.FRVN 


Extension File Number 


J 

1 


H.EFNU 


Extension File Seq, Num, 


i 

» 

1 

1 


H.EFSQ 


Extension RVN 


t 

1 

i 

1 


N. ERVN 




t 

1 


H.UFAT 



User Attribute Area 



File Character i sties 



! 



Cnot used) ! 

• I— - - ! 

Access Level I Mao Words in Use I 

- I ——I 

Fi Te Owner UIC -- I 

File P rotect ion I 

tataiai**«aiwap«s«eae«*wi«»«eaiaia»waeWM»ai«»«aaiae«is>«e«>«ie»*e | 

Record Protection ! 



Cnot used) 



Security Mask 



H.FCHA 

H.UCHA 



H, USE 
H.FOWN 
H, PROG 

H.PROJ 

H.FPRO 

H.RPRO 



H.SEMK 
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I S.HDHD 



I dent Area 



I 




I 




File Name 



Revision Number 



I.FNAM 



I.RVNO 



| m m 
| ■ m 

I m m 



Creation Date 



I.CRDT 



I 

I 



I.RVPT 



I 

!-- Revision Date 




I.EXDT 



! 




I 



Exoi rat i on Date 



Backup Date 



I.BKDT 



I 



I 



I.ULAB 
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User File Label 



S.IDHD 
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Mao. A c L i and Reserved Areas 



I 

I 

I 

I Ret r i eval Poi nters 



i Access control List 

I 

I 

I 




I Peserved Area i 

I I 

I 1 

I I 

| ——————————————————————————————————————— I 

! File Header Checksum 1 H.CKSM 

I — i 



a , 0 Directories 

Files-11 provides directories to allow the organization o b 
files in a meaningful way. While the File ID is sufficient 
to locate a file urdauelv en a volume set. it, is hardly mne- 
monic. Directories are files whose function is to associate 
symbolic names with File ID*s« 

The directory format a 1 so cont a i n s hooks for extensions in 
future systems. One of these is a construct known as a 
symbolic link* A symbolic link allows a di rectory to con- 
tain a pointer to a file which is not on the sane volume 
set. and cam therefore not be. represented by a File ID, A 
symbolic link therefore associates the file name with anoth- 
er ASCII strino. 
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4.1 Directory Hei rarehie.9 

Since directories are files' with no special attributes* di- 
rectories nay list files that are in turn directories. Thus 
the user nay construct directory heirarehies of arbitrary 
depth and complexity to structure his files as he pleases. 



4.1,1 Two Level Directory Hei rarchy - 

Implementations of Files-11 on existing PDP-11 systems all 
support a two level directory hei rarchy which is tied in 
with the user identification mechanism of the operating sys- 
tem. Each UIC known to the system is associated with a user 
file directory (UFD), References to files that oo not spec- 
ify a directory are generally defaulted to the UFD associat- 
ed with the user's UIC, The syntax used to refer to UIC's 
is the same as that used to identify the di rectory in a file 
name string. The construct ,, [n*m] H is used to refer to 
group number n, member number m. All UFO's are listed in 
the volume's master file di rectory (MFD) under a file name 
constructed from the di rectory strinq. (See section 5,3 for 
a description of the MFO.) A string of H tn*m]" associates 
with a directory name of "nnnmmm, DIR ; 1 " , where mnm and mmm 
are n and m padded out to three digits each with_ leadina 
zeroes. Note that all number conversions are done in octal. 

Two points should be noted here. The UFD structure des- 
cribed here is not intrinsically part of the Files-11 
on-disk structure? rather* it -is a convenient cataloging 
system applied by various operating systems. Also* there is 
no hard and fast relationship between the owner UIC of a 
file, and the UFD in which it is listed. Generally* they 
will correspond* but not necessarily. 



4.1,2 Mtil t i - 1 eve 1 Directory Hei rarchy - 

New implementations of Files-11 use a multi-level directory 
heirarchy, where the first level below the MFD is referred 
to as the user file directory (UFD) an.d subseouent levels 
are referred to as sub file directories (SFD's), Users are 
identified at the command level bv ASCII names; the svstem 
translates user names into UIC's internally. Thgg mFQ en- 
tries will correspond to the ASCII user names, A directory 
specifier will have the format " (namel . nameS. name3. ... 1", 
Each name in the list translates to a directory file name of 
the form "name.DIR;!" and is searched for in the current d i - 
rectorylevel. 

Observe that the directory protocol is ndt tied to the 
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structure level of the disk, Thus rew systems will always 
have tc handle the " [ n # m ] " construct# which maos to a UFO 
name of " nnnmmm, DIR ; 1 " and orovides only two levels of di- 
rectory, Old systems will not be able to handle volumes 



4.1,3 Multi-Volume Directory Structure - 

In a volume set# the MFD for the all of the user files on 
the volume set is the mfd of relative volume 1, Its entries 
can point to UFO's located on any. volume in the set# whose 
entries can in turn point to files and sub directories on 
any volume in the set. The MFC's of the remaining volumes 
in the set only list the reserved files on each volume. 

The assignment of volumes to specific directories and files 
is not covered by this specification. Different systems mav 
inclement different policies to trade off . factors such _as 
performance# reliability# and separability. Optimizing for 
performance# for example# usually means scattering the files 
as randomly as possible across the volume set to make the 
most use of the available multiple positioners. Maximum 
separability ■ (the ability to makeuse of only part of the 
volume setD^is achieved by locating files. on the same volume 
as their directories# and possibly entering the directories 
in the MF0' g of the volumes on which they reside. 



4,2 Directory Protection 



For directory operations# the record protection field is i n* 
teroreted specially by the directory manager. The four bits 
(described in the section on record protection) are inter- 
preted as follows; 



RP.90V 

PP.wPV 

«P.UPD 

PP.DEL 



Deny 1 ookuDS 

Deny entering new files 

Deny entering new versions of files 

Deny removing files 



Bv setting the accessor privilege level of a directory file 
acproor i atel y# the system (or user) may prevent users from 
rummaging through the di rectory using the normal file access 
methods. 

If record protection is not present. for_ a di rectory file# 
then the basic file access protection is used if it exists. 
Lookups renu i re 
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4.3 Directory Structure 

f 

A directory is a contiguous file# organized as a seauential 
file with variable length records# with the attribute set 
that records do not cross block bounda r i es# and no carriage 
control attributes. Directory entries within each block are 
oacKed together to' conform to , the variable length record 
format; a -1. byte count signals the. end of recordsfcr that 
block. (See section b for a discussion of record formats.) 
The entries in a directory are sorted a 1 Dhabet i c a 1 1 y # oer- 
mitting the use of an ootimized search. Entries which are 
multiple versions of the same name and type are arranged in 
order of decreasing version number to ootimize version^ re- 
lated operations, Each directory record consists of the 
following: 



| — I 

I Record Byte Count I 

I— - — ——I 

! Versionlimit ! 



! Marne Byte Count ! Flags 



I 

1 

! File Name St ri ng 



Va 1 ue Fi el d ! 

I 

! 



Count This two byte field is the standard byte count 

field of a variable length record. 

Limit This word contains the maximum number of versions 

that are to be retained for this name and type. 
An attempt to enter mere versions than the limit 
will result in 'the deletion of the least recent 
version# or an error return# at the implementing 
system' s ont ion. 

Flans This byte contains the type code of the directory 

entry and assorted flag bits. The tyce code is 
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Name 



Value 



contained In the three low bits of the flags byte. 
It Is one of the following values? 

DV.FIO The value lield Is a list of 

version numbers and 48 bit File Id's. 
OV.SLK The value field Is a symbolic 

link St r 1 ng. 

The following flag bits are defined? 

Set. if the ©receding directory 
record contains- the same name and tvoe 
as this one. 

Set if the next directory re- 
cord contains the same name and type as 
this one. 

This field contains the file name and type In 
ASCII# separated bv a a dot. The dot 19 present 
even if either name# or type# or both, are null. 
Only upper case alphabetic and numeric characters 
may be present In the .name and type. ff the 
length of the name is odd# It Is oadded with a 
slngl e nul 1 . 

This field contains the "value" of the directory 
entry* 1.e«# the Information returned to the user 
from a Icokuo operation. If the directory record 
Is a File ID list (the type field Is DV.FIO)# the 
value field Is a list of version numbers and cor- 
responding file ID's# appearing In descending 
order by version number. The number of entries In 
the list is deduced from the record byte count. 



OF.PFV 

DF.NXV 



.1 





Version Nymbei* 




— 


File ID 


m m 


m m 








Version Number 




m m 


File ID 


m m 


m m 




m m 



I 
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* 





Version Number 




m m 
m m 


File 10 


m m 
m m 



Version This word contains the version number of the' di- 
rectory entry in binary. Version numbers must lie 
in the ranee from 1 to 32767. 

File ID These three words are the file ID that the direc- 
tory entry points to. 

If the directory entry is a symbolic link (the 
flaas byte contains 0V.SLK1# then the value field 
is variable length. Its first byte is a byte 
count# and the. remainder is an ASCII strino which 
describes the linkage. The string Is ©added to 
the next word boundary with a null if necessesry. 
The format is the following* 



I I Byte Count I 

!— 1 1 



i i 

1 Symbolic Link String I 




5. B Reserved Files 



Clearly any 
the medium 
In Files— 11 
are created 



file system must maintain some data structure on 
which is used to control the. file organization, 
this data iskeot in several files. These files 
when a new volume is initialized. They are uni- 
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cue In that their File ID's are known constants. Note* 
however* that the relative volume number used when accessing 
one of these files deoends uoon the context. The exact 
number of these files which .Is present on a particular vo- 
lume mav varv; however* at least five must be present. All 
of these files are non-de 1 et abl e. These files have the fol- 
lowing uses? 

File 10 l * 1 ' 1 s the Index file. The Index file is the root 
of the entire Files-11 structure. It contains the volume's 
bootstrap block and the home block* which Is used to identi- 
fy the volume and locate the rest of the file structure. 
The Index file also contains all of the file headers for the 
volume, and a bitmap to control the allocation of file 
headers. 

File 10 2,2 Is the storage bitmap file. It Is used to eon- 
trol-the allocation of logical blocks on the volume. 

File ID 3,3 is the bad block file. It Is a. file containing 
all of the known bad blocks on the volume. 

File 10 Is the volume master file directory (or MFD), 
It forms the root of the volume's directory structure. The 
MFD lists the five known files* all first level user di rec- 
tories, and whatever other files the user chooses to enter. 

File ID 5*5 IS the system core Image file. Its use Is oper- 
ating svstem dependent; Its basic purpose is. to provide a 
file of known File ID for the use of the operating system. 

File ID 0,6 is the volume's free soace file. The blocks 
contained in this file are available for allocation by an 
alternate allocation scheme that does not drive off the sto- 
rage b 1 tmap. 

File ID 7*7 is the volume set. list file. If this volume is 
relative volume one of a tightly coupled volume set* this 
file contains a list of the labels of all the volumes In the 
set . 

File ID 8*8 is the volume backup Journal file. It ^contains 
a 1 oa of full volume and Incremental backuos performed on 
the volume. 

File ID 9,9 is the standard continuation file. If this vo- 
lume is part of a 1 oose 1 v „ coup 1 ed volume set* this file con- 
tains the first segment of the portion of the multi-volume 
file that resides on this volume. 

More File ID's may be reserved in the future; users should 
not make any assumptions about the values of user created 
FI 1 e ID's. 
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5.1 Index File 

The index file is File IP l#l, It is listed in the MFD as 
INDEXF, SYS } 1 . The index file is the root of the, Files-11 
structure, in that it provides the rears for identification 
and initial access , to a Files-tl volume# and contains the 
access data for all files on the volume (including itself). 
This file das the FCS, record format of 512 bvte. fixed lenoth 
records# with no carriage control. (See section 6 for a 
description of the FCS file format.) 



5.1.1 Bootstrap Bloch - 

virtual blech 1 of the index file is the volume's _boot 
block. It, is almost always mapoed to logical , block 0 of the 
volume. If the volume is the svstem device of an operating 
system# the boot block contains an operating system depen- 
dent crogram which reads the operating system into memory 
when the boot bl.ock is read and executed by a machine's 
hardware bootstrap. If the volume is not a svstem device# 
the boot block contains a small program that outputs a mes- 
sage on the svstem console to inform the operator to that 
effect. If block 0 of a volume is bad# it is permissible to 
map virtual block 1 of the index file to some other block. 
In this case, obviously# volume cannot be used as a svstem 
volume. 



5.1.2 Home 61 ock - 

virtual block 2 of the index file is the volume's home 
block. The purpose of the home block is to identify the vo- 
lume as Files-11# establish the specific identity of the vo- 
lume, and serve as the ground zero entry point into the vo- 
lume's file structure. The home block is, recognized as a 
home block bv the presence of checksums in known places and 
bv the presence of predictable values in certain locations. 

The home block is located on the first good block of, the 
home block search sequence. The search seauence Is of the 
form 



1 t n e delta# n 2 0# 1# 2# 3# 4 ...... 

The heme block search delta is computed from the geometry of 
the volume such that# if the volume is viewed as a three di- 
mensional space# the search sequence will travel approxi- 
mately down the body diagonal of the space. Since volume 
failures tend to occurr across one dimension# this minimizes 
the chance of a single failure dest-rovi ng ' bot h home blocks 
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of the volume. The search delta is eomouted from the volume 
geometry, expressed in sectors# tracks (surfaces)# and cyl- 
inders# according to the following rules# to handle the 
cases where one or two dimensions of the volume have a size 
of 1, 

Geometry} Delta 



s x 1 x 1 1 
1 x t x 1 } 
1 x 1 x c 5 

s x t x 1 } 
9 X 1 X C} 
1 X t X C } 

s x t x c s 



1 

1 

1 

s+i 

9 + 1 
t + 1 

( t+ 1 ) * s+ 1 



In most cases# the home block is located on L8N 1, 



5,1,3 Cluster Filler • 

If v, the cluster factor of the volume# is greater than 1# 
then the next v*2-2 blocks of the index file are cooies of 
the home block used to fill out the first two clusters of 
the index file. Note that# for cluster factors greater than 
1# this results in a wasted disk cluster. The benefit of 
this teehniaue is a_much simpler rule for finding the V8N of 
interesting parts of the index file. 



5.1.4 Backup Home Block - 

The backuo home block is a second copy of the home block lo- 
cated farther down the homeblock searchseouence, It per- 
mits the volume to be used even if the primary home block is 
destroyed. 

In general# the backup home block should be allocated on the 
second good block of the search sequence. If it is not# 
then all preceding blocks. on the seouence must net be avail- 
able for allocation. This is to prevent the situation of a 
malicious user constructing a counterfeit index file# which 
would be used if the primarv home block ever went bad. 

The c 1 u s t e r . wh i c h contains the backup home block is *aooed 
into the index file as virtual blocks v*2+l through v*3# 
where y is the volume cluster factor. Observe that the 
backuo home block may be located anywhere within this clus- 
ter# because there is no hard and fast relationship between 
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the cluster factor and the volume's track, and cylinder boun- 
daries, The entire cluster is therefore filled out with co- 
pies of the home block. 



5.1,5 Backup Index File Header - 

\ 

The next cluster of the index file contains a backup cosy of 
the indexfile header* so that data on the volume can be re- 
covered if the index file header goes bad. The cluster oc- 
cupies virtual blocks v*3+l through v*<4# where v is the vo- 
lume cluster factor. The LBN of the backup, index file 
header Is stored in location H.IHLB in the home block. The 
backup index tile header occupies the first block of this 
cluster? the remaining blocks are not used and their con- 
tents are undefined. 



5.1,6 Index File Bitmap - 

The index file bitmap is used to control the allocation of 
file numbers (and hence file headers). It is simply a bit 
string of length n # where n is the max i mum _ number of files 
permitted on the volume (contained in offset H.FMAX in the 
home block). The bitmap spans over as many blocks as is ne- 
cessary to hold it# i,e,» max number of. files divided by 
and rounded up. The number of blocks in the bitmap is 
contained in offset H.IBSZ of the home block. 

The bits in the index file bitmap are numbered seauentiallv 
from 3 to n-1 in the obvious manner# i , e, # from right to 
left in each byte# and in order of increasing byte address. 
Bit i is used to represent file number J + 1 s if the bit is 
1# then that file number is in use? if the bit is a# then 
that file number is not in use and may be assigned to a 
newly created file. 

The ingex file b i t mao, s t ar t s at virtual block v*u+i ©f the 
index file and continues through VBN y*a+m, where m is the 
number of blocks in the bitmap# and v is. the storage. map 
cluster factor. It is located at the logical block indicat- 
ed by offset H.IBLB in the home block. 



5,1,7 File Headers - 

The rest of the index file contains all the file headers for 
the volume. The first 16 file headers (for file numbers 1 
to 16) are logically contiguous with the index file bitmap 
to facilitate their location? the rest may be allocated 
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wherever the file system sees fit. ,Thus the first 16 file 
headers may be located from data in the home block (H.I9SZ 
and H.IBIB) while the, rest must be located through the mao- 
oing data in the index file header. The file header tor 
file number n is located at virtual block v*«fmtn (where m 
is the number of blocks in the index file bitmao# and v is 
the storaoe mao cluster factor). 

The FCS end of file mark for the index file is located at 
the last file header ever used,. All header blocks located 
before the EOF are subject to validation when used to create 
a new file. If the block contains garbage# the new header 
is assigned a file seagence number of 1* being the first yse 
of this header block. If the block contains a deleted file 
header* the new header is assigned a seouence number one 
higher than the one contained in the block, A block con- 
taining a valid file header must never be used to create a 
new file* even if it is marked free in the index file bit- 
mao, This prevents files from being lost if bits are 
drooped in the bitmap. Index file blocks beyond the EOF are 
assumed to contain garbage for the purpose of creating new 
file header s , 



5,1,6 Index File Layout - 

The following is a. sketch of the blocks in the index file. 
Observe that this illustration assumes a storage mao cluster 
factor greater than 2. 
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5,1,9 Home Block Details - 

The following is a detailed description of the home block. 
Note that all copies of the volume's home block contain the 
same data, with the exception of the cells containing the 
block's VBN and LBN, 

Items contained in the home block are identified by symbolic 
offsets in the same manner as items in the file header. The 
symbols may be defined in assembly language programs by cal* 
lino and invokino the macro H H R L 2 $ . which may be found in 
the macro library of any system that supports Files-11. 
Alternatively. one may find the macro in the file 
F11MAC.M4C, which is available from the author. 



5. 1,9,1 H.HRLB - 4 Bytes Home Block LBN 

This double word contains, the logical block number 
of this particular cocy of the home block. 



5. 1.9.2 H.AHLB - 4 Bytes Alternate Home Block LBN 

This double word contains the LBN of the volume's 
secondary home block. One may determine, when 
scanning the home block seauence. whether the 
block read is the primary or secondary home block 
by comparing H.HBLB and H.AHLB, This value must 
be non-zero for a valid home block. 



5. 1,9,3 H.IHLB - 4 Bytes Backup Index File Header LBN 

This double word contains the logical block on 
which the backup index file_header is located. 
This value must be non-zero for a valid home 
block. 




P*GE 
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5. 1.9 . u H.VLFV - 2 Bytes Structure Level and Version 

i 

The volume structure level and version Is used to 
identify different versions of Files-11 as they 
affect the structure of all. parts of the volume 
except the file header. This permits upwards com- 
patibility of file structures as Fi 1 es-1 1 . evol ves# 
In that the structure level word Identifies the 
version of Fl.les-11 that created this particular 
volume. This document describes structure level 2 
of Flles-11, The high bvte of H.VLEV must contain 
the value 2, The low byte contains the version 
number# which must be greater or eoual to 1. The 
version number will be incremented whenever compa- 
tible additions are made to the Flles-11 structure 
that .may be safely ignored by an old version of 
the file system. This document describes version 
1 of structure level 2, 



5.1. Q ,5 H.SBCL - 2 Bytes Storage Bitmap Cluster Factor 

This word contains the cluster factor used in the 
storage ..bitmap file. The cluster factor is the 
number of. blocks represented by each bit in the 
storage bitmap. This value Is also referred to as 
the volume cluster factor, x 



5. 1,9.6 H.HBVB - 2 Bytes Home ; 81oek VBN 

This. word contains the virtual block that this 
particular copy of the home block occupies in the 
Index file. This value must be non-zero for a 
valid home block. 



5. 1.9. 7 H.AHV8 - 2 Bytes Backup Home Block VBN 

This word contains the virtual block number that 
the cluster containing the secondary home block 
occupies in the index file. The contents of this 
word is v*2+l# where v is the storage mac cluster 
factor. 
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5.1. 9.6 H.IHVR - 2 Bytes Backup Index File Header VRN 

This word contains the virtual block number that 
the backup index file, header occuoles In the Index 
file, .The contents of this, word Is v*3+l> where v 
Is the storage mao cluster factor. 



5. 1.9.9 H.IBV8 - 2 Bytes -Index File Bitmap VBN 

This word contains the starting virtual block 
number of the index file bitmap. The contents of 
this word Is the value v*4+ 1 , where v is the sto- 
rage map cluster factor. 



5.1.9.15! H.IBLB - 4 Bytes Index File Bitmap LBN 

This double word contains the starting logical 
block address of the Inoex file bitmap. Once the 
home block of a. volume has been found, it is ,th1s 
value that provides access to. the rest of the 
Index file and to the volume. This value must be 
non-zero for a valid heme block. 



5.1.9,11 H.FHAX - 4 Bytes Maximum Number of Files 

This double word contains the maximum number of 
files that may be present on the volume at any 
time. This value must be greater than the con- 
tents of, .H.P8VF for the home. block to be valid. 
If the maximum number, of files is less than 65536, 
then the third word of File ID's referencing files 
on this volume is simply the relative volume 
number, and the volume set of which this volume Is 
a member may contain up to 65535 volumes. If the 
maximum number of files Is greater than or eoual 
to 65536, however, then the high byte of the third 
word of File ID's is the high byte of, the file 
number, and the volume set may consist of up to 
255 volumes. Under no circumstances may the maxi- 
mum number of files be greater than 2**24-l, 
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5.1.9.12 w.iBSZ - 2 Bytes Index File Bitmap size 

This 16 bit word contains the number o f blocks 
that make uo the index tile bitmap. This value 
must be non-zero tor a valid home block* 



5.1,9.13 H.RSVF - 2 Bytes Number ot Reserved Files 

This word contains the number of ot reserved tile 
on the volume. The tile sequence number ot each 
reserved tile is always equal to its tile number. 
Reserved tiles may not bedeleted. This word must 
contain a minimum value of 5 to be valid. 



5.1.9.14 H. DVT Y - 2 Bvtes Disk Device Type 

This word is an index identifying the type of disk 
that contains this volume. It is currently not 
used and always contains 0, 



5.1.9,15 H.RVN - 2 Bytes Relative Volume Number 

This word contains the relative volume number that 
this volume has been assigned in a volume set. If 
the volume is not oart of a volume set* then this 
*ord contains zero, 



5.1.9.16 H.NVQL - 2 Bytes Number of Volumes 

This word contains the total number of volumes in 
this volume set if the contents of H.pvn is 1 
(i.e.# if this volume is the first volume of the 
volume set). Otherwise# this word contains zero. 



5.1,9,17 H.VCHA - 2 Bytes Volume Character i st ics 

This word contains bits whieh provide additional 
control over access to the volume. The following 
bitsare defined; 

CH.NDC Set if device control functions are not 
permitted on this volume. Device con- 
trol functions are those which can thre- 
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aten the integrity of the volume# such 
as direct reading and writing of loqical 
bl oeks# etc. 

CH, NAT Set if the vc 1 ume _may not be attached# 
i.e,» reserved for the sole use by one 
task or user, 

CH.RCK Set if the volume is to be read checked. 

All block reads done on this volume# 
both for data and for file structure, 
will be performed with a read# 
react-compa re seauence to insure data in* 
tear i ty, 

CH.wck Set . if the volume is to be write 
checked. All block writes done on this 
volume# both for data _and for file 
structure# will be performed with a 
write# read-compare sequence to insure 
data integrity. 



5.1.9.16 H.VQWN - a Bytes Volume Owner UIC 

This double word contains the_binerv UIC of the 
owner of the volume. The format is the same as 
that of the file owner- UIC stored in the file 
header. 



5,1,9.19 H.VSHX • a Bytes Volume Security Mask 

These four bytes contain the security m.ask for the 
volume. In the same manner as the security mask 
of a file# the volume security mask controls the 
information categories that may be stored on the 
volume,' Only files whose security mask is a sub- 
set of the volume security mask may be written on 
the volume. Note# however# that the security mask 
of a user accessing files on the volume does not 
have to.be a superset of fhe volume mask, since he 
must still Pass the security mask check on the in- 
dividual files. Further# if such a check were 
made# the security masks of all files written on 
the volume would have to be eaual to the volume 
mask, which Is not very useful. 
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5.1,9.20 H.VPRO - 2 Bytes Volume Protection Code 

TMs word contains the orotectlon code for the en- 
tire volume. All ©Derations on all files on the 
volume must pass both the volume and the file oro- 
tectlon check- to be permitted. Accessors to the 
volume are categorized into system, owner, group, 
and world with respect to the volume owner UIC In 
the same manner as for file protection, -Each ca- 
tegory Is controlled bv the familiar four bit 
field. The four access modes are bit encoded as 
follows! 

VP.ROV Deny reading files 

V.p.wrv Deny writing existing files 

VP.CRE. Deny creating files 

VP, DEL Deny deleting files 



5,1.9,21 H.DPPR - 2 Bytes Default File Protection 

This word contains the file protection that win 
be assigned to all files created on this volume If 
no file protection is specified by the user. 



5.1.9.22 H.DRPR - 2 Bytes Default Record Protection 

This word contains the reco'rd protection that will 
be assigned to all files created on this volume if 
no file protection is specified by the user. 



5.1.9.23 H.CHK1 - 2 Bytes First Checksum 

This word is an additive checksum of all entries 
preceding In the home block (i.e., all those list- 
ed above). It is_comouted by the same sort of al- 
gorithm as the file header checksum (see section 
3. 5. 7.1). 



5.1.9.24 H , V D A T - 8 Bytes Volume Creation Date 

This area contains the date and time that the vo- 
lume was i n 1 1 i a 1 1 zed. _ It is In the same binary . 

•format used In the file header (see see t i on i.S 
3,4.2) . 




3 
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5.1.9.25 H.WISZ - 1 Svte Default Window Size 

This byte contains the number of . retrieval Po- 
inters that will be used for the "window" (in core 
file access data) when files are accessed on the 
volume# if not otherwise specified by the acces- 
sor. 



5.1.9.2b H.tRUC - l Byte Directory Pre-access Limit 

This byte contains a count of the number of direc- 
tories to be stored in the f i 1 e, system' s directory 
access cache. More generally# it is an estimate- 
of the number of concurrent users of the volume 
and its use may be generalized in the future. 



5.1,9.27 H.FIEX - 2 Bytes Default File Extend 

This word contains the number of blocks that will 
be allocated to a file when_a user extends the 
file and asks for the system def au 1 1 . va 1 ue for al- 
location. 



5.1.9.28 - - 388 Bytes Not Used 



5.1.9.29 H.SNAM - 12 Bytes Structure Name 

This areacontains the ASCII name of the volume 
set to which this volyme belongs# padded out to 12 
bytes with spaces. If this volume is not a member 
of a volume set# then this area is filled with 
nulls. 



5.1.9.30 H . I NON - 12 Bvtes Volume Name 

This area contains the volume label in ASCII, It 
is padded out to 12 bytes with soaces. It is 
placed here, in accordance with the proposed volume 
i dent i f 1 cat i on standard. 
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S. 1.9.31 h.inoO - 12 Bytes Volume Owner 

TMs area contains an ASCII string Identifying the 
owner of the volume*. The area is padded out to 12 
bytes with trailing spaces. It Is p1aced_here In 
accordance with the proposed volume Identification 
standard. 



5,1.9.32 H.INDF - 12 Bytes Format Type 

This field contains the ASCII string "DECFILE119” 
padded out to 12 bytes with spaces. It Identifies 
the volume as being of P11es*ll format# structure 
level 2, It Is placed here, In accordance with 1 the 
proposed volume 1 dent i f i cat i on standard. 



5.1.9,33 - - 2 Bytes Not Used 



5. 1.9.34 .H.CHK2 - 2 Bytes Second Checksum 

This word is the last word of the home block. It 
contains an additive checksum of the Preceding 255 
words of the heme block, computed according to the 
algorithm listed In section 3.5,7, 1, 
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5.2 Storage Bitmap File 

The storage bitmap file is File ID 2,2. It is listed in the 
MFD as BITMAP , SYS s 1 , The storage bitmap is used to control 
the available space on a volume. It consists of a storage 
control block which contains summary information about the 
volume* and the bitmap itself which lists the availability 
of individual bloeks. This file has the FCS record format 
of 51? byte fixed length records# with no carriage control. 
The end of file mark is positioned to point to the last 
b! oc k used. The storage bitmap tile must be contiguous. 
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5,2,1 Storage Control Block - 

Virtual block 1 of the storage bitmap is the storage control 
bloc'k. It contains, summary information about the volume. 
Note that i md ementat i on of some of the features in the sto- 
rage control block may require it to be written at mount and 
dismount, , 



5.2. 1,1 C.VUEV - 2 Bytes Storage Map Structure Level 

This word contains the structure level of the sto- 
rage control block. The high byte contains the 
value 2 to indicate Files-11 structure level 2. 
The low byte contains the version number# which 
must be equal to or greater then l. 



5,2, 1,2 C-.SBCL - 2 Bytes Storage Mao Cluster Factor 

This word contains the storage mao cluster factor 
of the volume. Its contents are identical to the 
contents of H.SBCL in the home block. It is 
placed here for convenience. 



5.2, 1.3 C.VSIZ - a Bytes Volume Size 

These four bytes contain the volume size expressed 
in logical blocks. 



5.2,1 , a C.BLKF - a Bytes Blocking Factor 

These words contain the blocking factor of the vo- 
lume? i.e,# the number of physical blocks or sec- 
tors that make up one logical block. 



5,2, 1.5 C , SECT - a Bytes Sectors Per Twack 

These words contain' the number of logical blocks 
in each track of the volume. 
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5.2. 1.6 
s. a. i.7 

5.2. 1.8 



5.2. 1.9 

5.2.1.10 

5.2.1.11 



C.TPAK - a Bytes Tracks Per Cylinder 

These wo rds , cent a i n the number of tracks contained 
In each cylinder of the volume. 



C.CVLN " 4 Bytes Number of Cylinders 

These words contain the total number of cylinders 
on the volume. The .above t h r ee _ ouant 1 t 1 es are 
present to assist optimized allocation of space on 
physical boundaries in the volume. 



C.STAT - 2 Bytes Status hord 

This word contains the followinq status bits! 

CS.TRN Volume in transition. This bit is set 
If the volume may be In an Inconsistent 
state because it was. not dismounted 
properly, A system which does write_on 
replace caching of the storage map* *or 
example# should .set this bit on mount 
and clear It on dismount. 



- - 488 Bytes (not used) 



C.CKSM » 2 Bytes Block Checksum 

This word contains the ubiquitous block checksum. 
It is comouted using the same algorithm as the 
file header checksum (section 3.5.7, 1), 
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5.2,2 Storage Bitmap - 

virtual blocks 2 through n+1 are the storage bitmap itself. 
It is' best viewed as a bit string ©\f length m* numbered from 
? to m— 1 > where m is the total number of aHocatab1e_ clus- 
ters on the volume roumded.up to the next multiple of 9096. 
Each cluster contains v logical bloeks# where v is the sto- 
rage mao cluster factor (also referred to as the volume 
cluster factor) contained in location H.SSCL in the home 
block. The bits are addressed in the usual manner (packed 
right to left in seauentiallv numbered bytes). Since each 
virtual block holds 9096 bits* n blocks* where n a m / 9 0 9 6 * 
are used to hold the bitmap. Bit J of the bitmap represents 
logical blocks j*v throuah j*v+v-l of the volume; if the 
bit is set* the blocks are free; if clear* the blocks are 
allocated. Clearly the last k bits of the bitmap are always 
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clear, where k is the difference between the true size of 
the volume and m, the length of the bitmap, 

Pounding the storage map file up to the next multiple of the 
volume cluster factor may resu 1 t _ 1 n some unused blocks at 
the end of t^e file. The FCS end of file mark points to the 
last block used. 



5, 3 Bad Block File 

' The bad block file is File ID 3.3, ,It is listed in^the MFC 
as B AD3LK.SYS } 1 , The bad block file is simolv a file con- 
taining all of the known bad blocks on the volume. This 
file has the FCS record format of 512 byte fixed length re- 
cords, with no carri age cont rol , The end of file mark may 
be placed as the operating system's bad block handling stra- 
tegy finds useful. Volume initialization should place the 
EOF at the end of the bad blocks found during initializa- 
tion, At all times, the EOF should, at least point cast the 
bad block descriptor data, described below. This ensures 
that the bad block data is preserved for future 

re- 1 n i t i a 1 i zat i on of the volume. 



5.3.1 Factory Sad Slock Descriptor - 

On disks which have factory generated last track bad block 
data, such as the RK06, RK07, and RM03, the first several 
clusters of the bad block file should include the last track 
of the volume. This track contains redundantly recorded 
descriptions of the bad blocks on the volume, as described 
in DEC STD. 144, "Disk Standard for Recording and Handlino 
Manuf acturi ng Detected Sad Sectors", 



5.3.2 Software Sad Block Descriptor - 

On disks that do not have factory last track bad block data, 
the first % .c1uster of the bad block file contains the bad 
block descriptor for the volume. It is always located on 
the last good block of the volume. This block may contain a 
listing of the bad blocks on the volume produced bv a bad 
block scan, program or diagnostic. The software bad block 
descriptor is most of a Files-11 Structure Level 1 header 
map area. The first two bytes contain the constants 1 and 
3, respect i vel y. The third byte contains the number of 
words that contain data, -The fourth bvte contains the 
number of words available for bad block data. The last word 
of the block contains the usual additive checksum. The re- 
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trieval pointers are structure level 1 format 1 pointers# as 
described below. 



Bad Black Descriptor Layout 



3 I 1 



I Map Words Avail, I Mao Words in Use 



I 

! 

! 

! Ret r i eval Poi nters 

I 



I Block Checksum ! 

I — — - I 



Each retrieval pointer is. four bytes in lenqth, 8yte 1 con- 
tains the high order bits of the 24 bit LBN, Byte 2 con- 
tains the count field, and bytes 3 and 4 contain the low 16 
bits of the LBN, 

! 1 ! 

! Count I High I 



I Low Order LBN I 



5,4 Master File Directory 

The master file directory Is File ID 4,4, It Is listed In 
the MFD (itself) as 000000, DIB j 1 , The. MFD Is the root of 
the volume's directory structure. It lists the reserved 
files, plus whatever the user chooses to. enter. The format 
of the mro is the same as all directory files, and is des- 
cribed in section 4.3, In the UFD structures described In 
sections 4,1,1 and 4,1,2, the MFD contains entries for all 
user file directories. 
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5.5 Core Image File 

The core image file is File 10 5*5, It is listed in the MFD 
as CPPIMG.SYS j 1, Its use is operating system dependent. In 
general * it provides a file of known File ID for the use of 
the operating system* for use as a swaoarea* for example* 
or as a monitor overlay area# etc. This file has the FCS 
record format of 512 bytefixed length records* with no car- 
riage control. The end of file mark is positioned to point 
to the physical end of file. 



5.6 Free Space File 

The. free space file is File ID 6*6, It is listed in the MFD 
as FREFIUSYSj 1. T*e space it contains is available for al- 
location to other file9. The presence of this file allows 
individual implementations of Files-11 to use an alternate 
scheme of space allocation which is more complex than using 
the storage bitmap alone* but has potentially much better 
performance. Systems which do not suoodrt . thi3 method of 
allocation should truncate this file to zero and return the 
space it maos to the storage bitmap before using the volume. 
This file Has the FCS, record format of 512 byte,, fixed length 
records* with no carriage control. Its end of file mark is 
undefined. 



5.7 Vo 1 ume Set L i st 

The volume set list is File ID 7*7, It is listed in the MFD 
as VOLSET , S YS » 1 , It is used only on relative volume. one of 
a tightly coupled volume set. There* it contains a list of 
the volume labels of the volumes contained in this volume 
set. The format of this file is FCS 64 byte fixed length 
records with implied carriage .eont rol • . The first 12 bytes 
of record 1 contain the structure name of the volume set. 
The first 12 bytes of record n contain the volume label of 
relative volume n-1. The remaining 52 bytes of each record 
are reserved for future use. 



5.5 Backup Log File 

The backup log file is File. Id 8*8*0,. It is listed in the 
MFD as BACKUP , SYS ? 1 . This file contains a historv of volume 
and incremental backups performed on the volume. Its format 
is at present undefined* 
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5.9 Continuation File 

The standard continuation file is File ID 9,9. It is listed 
in the MFO as EXTFIL. SYS ? 1 . It is used as the extension 
File ID when a file crosses from one volume _of a looselv 
couoled volume set to another. The purpose of this reserved 
File ID is allow a multi-volume file to be written seduen- 
t f a 1 1 v with only one volume mounted at a time. Ordinarily, 
when a file is extended onto another volume, the new header 
must be created first to obtain the new File ID before the 
extension linkage in the current header can be written. The 
use of this reserved File ID allows_the extension linkage to 
be written with a known constant before the next volume is 
even on line. 



6.0 FCS Pile Structure 

File Control Services (FCS) is a user' level interface to 
Files-11 implemented in the RSX-11 systems. Its principal 
feature is a record control facility that allows sequential 
processing o* variable length records and seauential and 
random access to fixed length record files. FCS interfaces 
to the victual block facility provided by the basic Files-11 
structure. 



6.1 FCS File Attributes 

FCS stores attribute information about the file in the 
file's' user attribute area CH.UFAT' - see sec t i on 3 , 5 . 2 . 1 3) • 
It uses only the first 7 words? the rest are ignored by 
FCS, The following, items are contained in the attribute 
areas they are identified by the usual symbolic offsets 
(relative_ to the start of the attribute area). The offsets 
may be defined in assembly language programs by calling and 
invoking the macro FDOFFS DEFSL. Flag values and bits mav 
be defined bv calling and invoking the macro FCSRT$ . These 
macros are in the system macro library of any operating sys- 
tem that supports Files-11, Alternatively, all these values 
are defined in the system object library of any system that 
supports Files-11, and may be obtained at link time. 



6.1.1 P.PTVP 1 Svte Record Type - 

This byte identifies which type of records are 
contained in this file. The following three va- 
1 ues are 1 egal : 
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R.FIX Fixed length records, 

R.VAR Variable length records, 

R.SEQ Seauenced variable length records 



6,1,2 F.RATT 1 Byte Record Attributes - 

This byte contains record attribute bits that con- 
trol the handling of records under various con- 
texts, The following flag bits are defined? 

FD.FTN Use Fortran carriage control If set. 

The first byte of each record Is to be 
1 interpreted .as a standard Fortran car- 
riage control character when the record 
Is copied to a carriage control device, 

FO, CR Use imp!1ed_ carriage control If set. 

When the file is cooled to a carriage 
control device, each record Is to be 
preceded by a line feed and followed by 
a carriage return. Note that the FD.FTN 
and FD.CR bits are mutually exclusive, 

FP. B.LK Records do not cross block boundaries If 

set. Generally, there will be dead 
scats at the end of each block? how 
this is handled is explained In the des- 
cription of record formats in section 
6 . 2 , 

FD.PRN - Use print file carriage control. Legal 
only If the record type Is R.SEQ, The 
leading two byte field of. each record Is 
used as carriage control instead of as a 
sequence number. The first and second 
bytes are used as leading and trailing 
carriage formatting, respectively. The 
i nterpretat i on of the carriage control 
bytes Is described below In section 
6.2.3, 



6,1,3 F.RSIZ 2 Bytes Record' Size - 

In a fixed length record file, this word contains 
the size of the records In bytes. In a variable 
length record file, this word contains the size In 
bytes of the longest record In the file. 
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6,1 ,n F.HIBK a Bytes Highest VBN Allocated - 

TMs 32 bit nuober is a count of the number of 
virtual b 1 pc ks , a 1 1 ocat ed to the file. Since this 
value is maintained by FCS# it is usually corre-ct# 
but it is not guaranteed since FCS is a user level 
eackage. 



6.1.5 F.EFRK a Bytes End of File B1eek v - 

T M 9 32 bit number is the VBN in which the end of 
file is located. Both F.hibk and F.EF8K are 
stored with the high order half in the first two 
bytes# followed by the low order half. 



6.1.6 F.FFBY, 2 8yte9 First Free Byte - 

This word is a count of the number of bytes_inuse 
in the virtual block containing the end of file? 
i.e.# it is the offset to. the first bvte of the 
file available for appending, Mote that an end of 
, file that falls on a block boundary may be repre- 
sented in either of two wavs. If the file eoiy 
tains precisely n. blocks# F.EFSK may contain n and 
F.FFBY will contain 512. or F.EFBK may contain n+1 
and F.FFBY will contain 0, 



6.1.7 S.FATT Bytes Size of Attribute Block - 

This symbol . represents the total number of bytes 
in the FCS file attribute block. 



f 

6.2 FCS File Attributes Layout 



F . R A T T 



1 Record Attr, I Record Type 



I Record Size (Bytes) ! 

! - - I 

! Highest vbm ! 

i Allocated i 

I---— — ! 

1 End of File ! 

!-- —I 



F.RTYP 

F.PSIZ 

F.HIBK 



F.EFBK 
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! 



V8N 



I 



First F ree Byte 



I 

I 



I 



F.FFPY 

S.FATT 



6.3 Attribute Standardization 

To assurers certain consistency of file record structures, 
certain fields in the record attributes area are standard- 
ized, and nust contain well defined values regardless of the 
record structure or file organization in use, 

1, The record type byt ; e (F.RTYPE) must contain a code 
that identifies the file organization and record 
structure, _ All codes must be registered with this 
SDec 1 f i cat i on, 

2, The record attribute bits should be used as des- 
cribed above when applicable. New attributes 
ahould be registered with t h i s spec i f i cat i on, 

3, The high VBN field (F.HIBK) must contain the number 
of b 1 oc ks a 1 located to the file, Fi 1 e . managers may 
modify this field during some operations on the 
file. 

a. The end of file mark CF.EFBK and. F.FFBY) should 
describe the end of data in the file when applica- 
ble. 



6,4 Record Structure 

This section describes how records are packed in the virtual 
blocks of a disk file. In general# FCS treats a disk file 
as a seauentially numbered array of. bytes. Records are num- 
bered consecutively starting with 1, 



6.4.1 Fixed length Records- - 

In a f i 1 e cons i st i ng of fixed length records, the records 
are simply packed end to end with no additional control in- 
formation. If the record length is odd, each record is pad- 
ded with a sinale null. Fop direct access, the address of a 
record is computed as follows! 

Let! n s record number 
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k s record size (in bvtes) . 
ns bvte address of record in file 

0 s number of, records eer block 

] s VBN containing the start of the record 

1 = bvte offset within VBN J 

Then h s ((k+l)/2)*2 (rounded uo record length) 

m s ( n- 1 ) *h 

j = m/512+1 (truncated) 
i s m mod 512 , 

The previous discussion assumes that records cross block 
boundaries (that is* FD.8LK is not set). If records do not 
cross clock boundaries* they are limited to 512 bytes* and 
the following eouations aooly (the variables are defined as 
above) ? 



h = C(k+l)/2)*2 (rounded uo record length) 
a = 512/h (truncated) 
j * (n-l)/a+l (truncated) 
i s ( ( n- 1 ) mod o) *h 



6, a, 2 Variable Length Records - 

In a file consisting of variable length records* records may 
be uo to 32767 bytes in length. Each record is preceded by 
a two bvte binary count of the bvtes in the record (the 
count does not include itself). For examole* a null record 
is recresented by a single zero word. The bvte count is al- 
ways word aligned} i,e,* if a record ends on an odd bvte 
boundary* it is oadded with a single null. 

If records do not cross block boundaries (FD.8LK is set)* 
they are limited to a size of 510 bytes, A bvte count of -1 
is used as a flag to signal that there are no more records 
in a particular block. The remainder of that block is then 
dead space and the'next record in the file starts at the be- 
ginning of the next block. 



6.4.3 Seauenced Variable Length Records - 

The format of a seauenced f i 1 e i s i dent i cal to a variable 
length recorg file excent that a two byte seouence number 
field is located immediately after the byte count field of 
each record. This field contains a binary value which is 
usually interpreted as the line number of that record (see 
Section 6,1,2 FD.PRN and Section 6, 2, 3,1). The seouence 
number is not returned as part of the data when a record is 
read* but is available separately. Note that the record 
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byte court "Field counts the sequence number field as well as 
t^e data of the record. 



6.4,3. 1 Format of Two Byte Print Control Field in R.SEG Re- 
cords - 

If the FD.PRN bit is set in the record attribute then the 
two byte "sequence number" field is.u^ed to contain carriage 
control data f~or the record. Byte 0 is print control infor- 
mation to act. upon before the. record data. is output to a 
unit record device} byte 1 is print control information to 
act ueon after the record data has been output to a unit re- 
cord device. 

The format of each byte is as follows} 



Bit 7 Sits 6-0 Hearing 

0 0 Ho' carriage control 

0 coumtCl-127) "count" new lines (CR/LF) 



Bit 7 Bit 6 Bit 5 Bits 4-0 Meaning 



1 

1 

1 



8 0 ASCII C0 set ASCII char to 

output (CRjiFF etc.) 

0 1 ASCII Cl set ASCII char (8 bit code) 

to output 

1 0 code C 0—63 5 Device specific code 



1 



Reserved 



NOTE 

The print control field is not currently supported 
bv FCS or RMS-11, 
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7.0 Record Management Services CRMS) 

Record Management Services CRMS) is a user level interface 
to Files-11, It provides a flexible means. of data storage# 
retrieval# and modification through a combination of file 
organization and record access modes, .File organization is 
the structure of data within the virtual blocks of a 
Files- 11 file# and record access mode is the manner in which 
storing and retrieving the data in the file occurs, 

Rms suooo rt s/def i nes three file organi 2 at i ons which ares 

, Seauential - compatible with FCS fixed# variable# 
and seouenced variable record files (see Section 6) 

. Relative » RMS oni v 

, Indexed - RMS only 

RMS interfaces to the virtual block facility erovided bv the 
Fi 1 es-1 1 st ructure. 



7.1 Data Formats and Representation 



RMS’suoPorts file organ i zat i ons which reouire a more complex 
degree of structuring than that reauired bv FCS, RMS also 
stores binary values in a different manner in general than 
Files-11 defines. For these reasons the data format and re- 
present at i ons used by RMS are given in the following sec- 
tions. 



7.1.1 String Storage - 

All strings. are stored left Justified. The left mpst char- 
acter is in byte n and the right most character is in byte 
N+M-i where M is the length of the string. 



7.1,2 String Character Code Set - 

All string values are assumed to be in the 7-bit ASCII code 
set . 
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7.1.3 String Collating Sequence - 

The collating seouenee used is the 7-bit ASCII code set 
where Nlj L is the lowest valued character and DEL is the hi- 
ahest valued character. 



NOTE 

The internal representation of ASCII characters on 
^0? * 1 1 systems is 7-bit ASCII, The string comoare 
routine of FMS-11 however*, performs a full Srbit un- 
signed compare oer character, RMS does not perform 
any "clear bit 7" code on incut or output ooera- 
tions. This allows the suoport of user binary bvte- 
strings* the KANA character set used in Japan* and 
in the future 8-bit ASCII when defined* without RmS 
modi f i cat i ons since the true colatinq seauence is 
lowest character * 0 and highest character = 255, 



7.1.4 Unsigned Binary Value Storage - 

All unsigned binary values are stored with the Least Signi- 
ficant Bits (LS8) in byte N and the Host S i gn i f i cant B i t s 
(MSSD in byte N+M-l where M is the length of the binary 
value. 

EXAMPLES 2 byte unsigned binary value 



I LSB. | N 



| MSB I N+l 



7.1.5 Signed Binary Value Storage - 

All signed binary values are stored as unsigned binary va- 
lues except that rest significant bit (bit 7 of byte n+m- 1) 
of the value is interpreted as the sign of the value. 
Negative numbers a»*e stored as the two's complement of the 
cos i t i ve va 1 ue. 
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EXAMPLE: 2 byte signed binary value 



I LSB IN 

I ! 

SSI MSB I Nfl 



7,1,6 Pointer Values ■ 

All Pointers are stored as unsigned binary values. Pointers 
are stored variable length. The length of a oointer value 
is scarified by the control bits ^associated with the po- 
inter. The length redui rement for a Pointer is determined 
by the nange of VBN values it falls in as follows* 

2 bytes start VBN 1 - 65,535 

3 bvtes start VBN 65,536 - 16,777,215 

a bytes start VBN 16,777,216 - a, 29a, 967, 295 



7.1.7 Bucket Pointers - . 

A bucket oointer is a pointer value which specifies the 
start VBN of the bucket. The length of the bucket (number 
of YBN's in bucket) is interpreted in the context of its 
usage within the file, and is specified in the file's Prolog 
data, 

EXAMPLE: 2 bvte bucket pointer 



! LSB IN 

1 ------ | 

! MSB 1 N+l 



7.1,8 Record Pointers - 

Record pointers are composed of two fields, a one byte re- 
cord ID field followed by a bucket oointer. The ID is used 
as a un i oue reeordidentifier for records within a bucket. 
The records are tagged with their ID'S when stored in the 
bucket, 

EXAMPLE: 3 byte record pointer 
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I ID I N RECORD ID 
! I 

! 159 ! N+l BUCKET POINTER 

, m m m m m m m j 

| MSB | N + 2 



7,1.9 Packed Decimal Strings - 

Packed decimal strings are from 1 to 16 bytes in length. 
The format is as follows* 



7 


4 3 


0 


! dl 


1 d2 


1 A 


1 d3 


! d4 


! A+l 


• 

• 

* 


! di 


1 s i qn 


1 A+N-l 

m m 



where; 

d = digit in the range of 8 thru 9 (binary 
value) 

sign is plus if value is 18# 12# 14# or 15 
sign is minus if value is 11 or 13 
N is length of strings in bytes 

i_= (N-l)*2+l and is an odd number in the range 
of 1 thru 31 

dl is most significant digit (mav.be a leading 
zero) 

di is least significant di'git 




■* 
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7.2 RMS FI 1 e Attributes 

R M $ stores at t ri bute Information about the file in the 
file's user attribute area CH.UFAT * see Section 3. 4, 1,9). 
It uses the first ten (10) words; the rest are reserved bv 
RMS, The following Items are contained In the attribute 
area; t.hey are Identified by symbolic offsets Into an R M S 
Interna) structure. The relative offset Into the attribute 
area may be calculated by subtracted FSFORG from the given 
offset name/value. The of f set def i nl t 1 ons may be defined In 
assembly language programs by calling and Invoking the macro 
IFAQFS RMSSL. Flag values and bits may be defined by cal- 
ling and Invoking the FABSBT DF I NSL . mac ro. These macros can 
be found In the RMSMAC.MLB maero library on all PDP-11 sys- 
tems supporting RMS, 



7.2,1 FSFORG 1 Bvte « Record Format and File Oroanizatlon 

This byte identifies the file's organization and 
which tyoe of reeord format it contains. The re- 
cord format is contained in bits 3 - 3» and the 

file's organization Is contained In bits 4-7. 
The symbolic values are defined such that they may 
be OR 'ED to yield the contents of the FSFORG 
field. 

Record Formats; 

FgSUOF Undefined record format (Block I/O only 
file) 

FBSFIX Fixed length records 
FBSMAR Variable length records 

FBSVFC Variable with Fixed Control (VFC) records 

(the FCS R.SEQ Isa sc ee la! case form of 
the regord format i,e,» the fixed control 
area is two bytes long and contains the 
records seauence number) 

FBSSTM ASCII stream records. RMS-11, used only 
as a means for RSTS/E ASCII data Inter- 
change, Records are delimited by verti- 
cal form effecter characters (LF» VT, FF 
and CR/LF pairs). 

File Organizations; 

FBSSEQ Seguential File organization (FSSSEQ a 3 
to maintain compatibility with FCS) 
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FBSPEL Relative File organ i zat 1 or 
F S $ I D X Index File organization 

FBSWSH Hashed File Organization (not implemented) 



7.2,2 FSRATT l Byte - Record Attributes 

This bvte contains record attributes bits that 
control the handling of records under various con- 
texts. The following flag bits are defined! 

FB*FTN See Section 6.1,2 FO.FTN 

FBSCR See Section 6,1.2 FO.CR 

F R $ P R N See Section 6.1,2 FD.PRN and 6.2.3, 1 

FBS8UK Record do not cross block boundaries for 
the Seauential fi 1e 'organization if set. 
See Section 6,1,2 FO.slLK for more deta- 
il. 



7,2.3 FSRSIZ 2 Bytes - Record Size 

In file containing fixed length format records 
this word contains the size of the records in 
bytes. In Sequential files containing variable or 
variable with fixed control formatted' records this 
field contains the size in bytes of the_ longest 
record in the file. This field is undefined for 
Relative and Indexed files containing variable or 
variable with fixed control format records. 



7. 2. a FS.HVBN 4 Bytes - Highest VBN Allocated 

R M S updates this field whenever the file is opened 
for write access. For details on this field see 
Section 6.1,4 F.HI3K. 



7.2.5 F5HE0F o Bytes - End of File Block 

This 32 bit number i.s the VBN in which the end of 
file is located for the Seauential file organiza- 
tion, Both FSHVBN and R$HE0F are stored with the 
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high order Half In the first two bytes# _ fol 1 owed 
by the low order Half, The low order half is sym- 
bolically referenced by FSLVBN and FSLEQF resoec* 
tivelv. These are the only two places that RMS 
stores block numbers in this manner (see Section 
7,11# and is done so to maintain comoat i b i 1 i t v 
with FCS. The Relative and Index file does not 
use this field and i'ts value is usually (but not 
guaranteed) either the contents of FSHV8N or the 
contents of FSHVBN plus one. 



7,2.6 P $FFBY 2 Bytes - First Free Byte 

This field is used for the Seauential tile oraani- 
zation as a count of the number of bytes in use in 
the virtual block containing the end of file. The 
Relative and Indexed f i 1 e organ i zat i on do not use 
this field and its value will be either 0,or 512. 
For more details on this field see Section 6,1.6 
F.FF9Y, 



7.2.7 FS3KSZ 1 Bvte - Bucket size 

This field contains the bucket size or maximum 
bucket size for the Relative and Indexed file or- 
ganization respectively. The. bucket size is re- 
presented. as the number of virtual blocks it con- 
tains. Legal values are from.l -.32, For compa- 
tibility with FCS a value of 0 is interpreted as 
1 . 



7.2,8 FSHOSZ 1 Byte - Fixed Header Size 

This f i el d contai ns the number of bvtes (1 - 255) 
in the fixed control area when the file contains 
Variable with fixed Control format records, . A 
value of 0 is interpreted as 2 so that compatibil- 
ity with FCS'S Seauenced Variable length record 
format file (R.SEQ) is maintained. 



7.2.9 fshrs 2 Bytes - Maximum Record Size 

This field contains a user specified maximum re- 
cord size limit in bytes# to be enforced on cutout 
operations. Files containing Fixed length format 
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reecrds have_ F$mrs set equal to FSRSIZ. For all 
other record formats FSMRS is set to the user 
specified_ value qiven when the file was created. 
A value of <3 i s i nteroreted as no maximum record 
size limit ssec i f i ed. 



7.2.18 FSDEQ 2 Bvtes - default Extend Quantity 

This field contains a user soecified default file 
extend quantity to be used whenever RMS needs to 
extend the file. A value of 0 is interpreted as 
use the volumes default extend. 
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7.2.11 


RMS 

l , 


File Attributes Layout - 


_ _ _ _ j 






1 

t . 


Record Attr, ! File Org./rec 


fmt i 


FSFORG 




1 

1 

1 - 


Record Size (bytes) 


1 


FSRSIZ 




1 — ' — — — w — ~ — - 

! Hiqhest VPN 

| mm 

! All ocat ed 


1 

m m ] 

1 


F $ H V 0 N 




1 End of f i 1 e 

I VBN 

l _ . 


! 

■ *» J 

1 


FSHEOF 




I 

1 


F i r 3 1 F ree Byte 


! 


FSFFRV 


FSHOSZ 


1 * 

1 

i _ 


Fixed Ctr, Size 1 Bucket size 


I 


F $ B K S Z 




i 

! _ 


Maximum Record Size Limit 


I 


F$mrs 




♦ 

1 

1 

i - 


Default Extend Quantity 


m m m m , 

i 


FSDEQ 


t 

To calculate 
file header 


the offset into the User Attributes area 
subtract FSFORG from all symbolic offsets 


in the 

• 



7,3 Prologue 81 ocks 

The P MS Relative and Indexed file organi zat i ons use the 
first several virtual blocks of the file to contain addi- 
tional file description data. This area of the file is 
called the file prologue. In the Relative file organiza- 
tion» the prologue is exactly one block lonoj in ,the_ In- 
dexed organization its length varies. The symbolic offset 
names, and flag values and bits used in the file prologue 
blocks and record formats may be obtained by calling and in- 
voking the following macros from the RMSMAC • M L8 macro libra- 
ry on all PDP-11 systems supporting RMS, 



ARDOFS 


RMSSL 


BKTQF-S 


RMS SL 


KDXOFS 


RMSSL 


K D X S B T 


DFINSL 


X A 8 S 8 T 


DFINSL 


8KTSBT 


0 F I n s. L 



The last word of every orologue block contains the standard 
Files-11 check sum (see Section 3.4,a.i), 
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7.3.1 Prologue Block 1 (VBN 1) - 

Prologue Block 1 contains common data, for. both the Indexed 
and Relative files# and file organization dependent data. 
The major Indexed file dependent data is the orimary . kev de- 
finition Cthe KSXXXX symbols). The major Relative file de- 
pendent data are the maximum reeond number# ''the address of 
the first data bucket# and the "real" End of File Block 
(last initialized# zeroed# V3N) , The orimary.key definition 
offsets (KSXXXX) are used for all key definitions within the 
orologue of the index file and are relative to the start of 
each key descriptor. 

The key definitions supply all the information needed by RMS 
to retrive# insert# update#, and. delete records for the in- 
dexed * i 1 e organization. The basic data which are contained 
in a key definition are as follows: 

, where the associated key field is positioned in the 
record# and how long it is. 

, The V9N address of the associated Root bucket. 

. Various key field options 

The key definitions are. linked into a ehain by the VBN ad- 
dress and. byte offset within the prologue block for the next 
key definition. The Indexed file organization can be viewed 
as a mu 1 1 i -oart i t i oned f i 1 e. The first partition is the 
orologue# the second partition is the i ndex assoc i ated with 
the primary key’ definition# and the third partitionis the 
user data associated with the primary index. Every indexed 
organized file contains these three partitions. In addition 
when alternate keys are defined then two additional parti- 
tions per alternate key are created. The f i r st pa rt 1 t i on is 
the index associated with the alternate key definition# and 
the second partition is the. RMS data associated with the 
index. TheRMS data contain pointers into the user data 
partition for the records meeting the various key values. 
The index is structured as ann'ary tree where the nodes _of 
the index are buckets. The index structure is the same for 
all key definitions. 



7.3, 1.1 k$nlvb 4 Bytes'- VBN for Next key Descriptor 

This field contains the virtual block address in 
which the next key descriptor may be found. This 
field is only looked at when the KIBNVT field con- 
tains a . 0 . When K5NLVB and MNBYT = 0 the last 
key descriptor has been found. The least signifi- 
cant 16 bits c f the VB^ 1 are stored in K S N L V B and 
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the most significant 1 6 > bits are stored In 
KSNLV8+2 (K$NHV9). 



7.3, 1.2 KSNBYT 2 Bytes - Bvte Offset for Next Key Deserlc- 
tor 

This word f lei d. contains the byte offset relative 
to the beginning of the VBN contained in KSNLVB 
for the next key descrlotor In the .chain of key 
deserlntors. The first_kev descriptor contained 
In a V9N starts at byte offset 0# and the chain 
will thread through the current VBN before goina 
to the next VBN. This means .that the VBN will 
only change when KSNBYT contains a 0. 



7. 3. 1.3 K$IAN 1 Byte - Index Area Number 

This byte contains the number of the Allocation 
Area to use for the index buckets associated with 
this key starting at level 2 aoing up to and in- 
cluding the Root bucket. 



7,3.1. « KSL.AN l Byte - Lowest Level Index Area Number 

This byte contains the number of the Allocation 
Area to use for Level 1 of the Index buckets asso- 
ciated with this key (a value of 3 means use the 
contents of K$ J A N ) , 



' 7.3. 1.5 KSDAN 1 Byte - Data Level Area Number 

This field contains the number of the Allocation 
Area to use for the data level (level 0) of the 
Index buckets associated with this key descrlotor. 



7.3. 1.6 KSLVL 1 Bvte - Level of Root 

This field contains the level number of the Root 
bucket associated with this kev descriptor. This 
field Is not supported by R^S-li release one. 
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7.3. 1.7 KSIBKS 1 8yte - Index Bucket Size 

This field contains the bucket size in VBN'S for 
all index levelClevel 1 through the root level) 
buckets (1 - 32) for this key descriptor. 



7.3. 1.8 KSDBKS 1 Byte - Data Bucket Size 

This field contains the bucket size in VPN'S tor 
all data level (level 8) buckets (1 - 32) for this 
key descriptor. 



7,3, 1.9 PSDBkS 1 Byte - Data Bucket Size 

This is a symbolic redefinition of KID8KS for use 
by the Relative file organization. 



7.3,1.13 KSLVBN 4 Bytes - Address of Root Bucket 

This field contains the bucket address of the Root 
bucket for the index associated with this kev des- 
criptor, The 32 bit V B N is stored in the manner 
described in Section 7, 2, 1,1, 



7.3.1.11 KSFLGS 1 Byte - Key Descriptor Flaps 

.* 

This field contains a bit vector for the various 
key options supported by RMS as follows! 

XB$0UP Duplicate key values allowed 

XBSCHG Key value may change on SUPDATE opera- 
tion 

XBSNtJL Null key. character enabled ( KSNULL) 

XBSINI Index must be initialized 

when the XBSINI hit is set the KSlVBN field con- 
tains the followings 

KSLVBN s C(KSDAN) 

KSLVBN+1 = C(K$fAN) 

KFLVPN+2 = C(K$LAN) 

KSLV8N+3 s 3 not used 
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This i n format i cn i s . used once only when the index 
for this key definition is created. Since the 
area number information is not normally stored in 
the in memory data ba9e for an open indexed file 
the required area numbers to create the index are 
stored in the root bucket field for this once only 
operation. The area numbers are not needed in the 
in memory data base since on future bucket alloca- 
tion the area number stored in the bucket which is 
"splitting" is used as the area number to allocate 
the new bucket from (see section 7.5,1,1,25, 



7.3.1.12 PSFLGS 1 Byte - Proloaue Flags 

This field is a symbolic redefinition of the 
K $ F t G S field foruse by the. Relative file organi- 
zation, Bits defined for this field are: 

PRSNEX Error eneounted extending Relative file 
no further extending is possible. 



7,3.1.13 KSOTP i Byte - Data Type for Key 

This field contains the data type of the key field 
within the user data records. The only legal 
value currently for RMS-11 is XBSSTG. The follow- 
ing data types are defined. 



X 8 $ S T G 
X B$ I Ni 2 
X9SBN2 
X8SIN4 
X B $ 8 n a 
XBTPAC 



String data. type (unsigned 8-bit bytes) 
Signed 15 bit.integer (2-bytes) 

Unsigned 16 bit binary (2 bytes) 

Signed 31 bit.integer (4-bytes) 

Unsigned 32 bit binary (4-bytes) 

Packed decimal (1-16 bytes) 



7 , 3 , 1.14 K$NSEG 1 Byte -Number of Segments in Key 

This field contains the^number of segments (1 - 8) 
that make up the definition of the logical key 
field. The X9SIN2, X8S8N2, X6SIN4, X8S0N4, and 
XBSRAC key field data types may only contain one 
(1) segment. 
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7.3.1.15 



7.3.1.16 



7.3. 1.17 



7.3.1.18 



7.3.1.10 



7.3,1.20 



KINULL 1 Svte - "NULL" Character 

This field contains a . user specified character,. 
If the key field within the data record associated 
with this key descriptor contains only "null" 
characters the record will not be inserted into 
the associated Index, The "null" value for the 
X P $ I N 2 # XBSBNS, XBSIN4, X8SBN4, and X 9 $ P A C key 
field data tyoes is defined as zero (3), This 
field is enabled by the X8SNUL bit in the KSFLGS 
and is only valid for alternate keys. 



K * K Y S Z 1 8yte - Total key Size 

This field contains the' sum. of all the key seqment 
sizes to yield the total size of the key field in 
bytes Cl - 255). 



KSKEY 1 Byte - key of Reference 

This field contains the key of reference number (0 
- 254) for this key descriptor. Primary key = 0} 
alternate keys = 1 - 254, 



K * M I N L 2 Bytes - Minimum Record Lenoth 

This field contains the minimum lenoth record in 
bytes to contain the complete key field. 



KSIEIL 2 Bytes * Index Fill Quantity 

This field contains the number of bytes to use for 
index level buckets (levels l - n) before a bucket 
split is considered. when the user reauests P*S to 
follow fill quantities. 



KSDFIL 2 Bytes - Data Fill - Quantity 

This field contains the number of bytes to use for 
user level buckets (level 3) before a bucket split 
is considered when the user reauests RMS to follow 
fill auant i t i es. 




■* 
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7.3,1.21 KSPOS 16 Bytes - Key Segment Offset Positions 

This is a set of eight C 8 3 2 byte fields 
(KSPOS0-KSPOS7) which contain the relative offset 
(0 - n) into the data record for each key segment. 



7,3.1.22 KSSIZ 9 Bytes - Key Segment Size 

This is a set of 8 1 byte, fields ( K$$ I Z0-K$S I Z7 ) 
which contain the size in bytes for the key seg- 
ment. 



7.3.1.23 KJKNM 32 Bytes - Key Name 

This is s 32 byte string supplied by the user when 
the key was defined. If not supplied will contain 

NULLS. 



7.3.1.24 KSLDVR 4 Bytes - First Data Bucket 

This field contains the bucket address of the 
first bucket at the data' level (level 0 ) associat- 
ed with this key descriptor. This field is not 
supported by RMS-11 release 1 and contains a zero. 



7.3,1.25 14 Snare Bytes - 



7.3,1.26 PSAV9N 1 Byte • v BN of First Area Descriptor 

This field contains the VBN (2 - 255) of the first 
Allocation Area descriptor block. Allocation Area 
descriptor blocks are virtually contiguous and are 
directly accessed by area number. See Section 

7.2.3. 



7.3.1.27 PSAMAX 1 Byte - Maximum Number of Areas 

This field- contains the. maximum number of defined 
Allocation Area descriptors ( 1 - 255) for this 
file. Eight (8) Allocation Area descristor can 
fit in a virtual block since each area descriptor 
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<s 64. bytes lonq, The file address of any Area 
descriptor ray be cal eu-1 ated- as follows: 

Lets a s area number (0 » 254) 

v s V B N address for a 
o a offset into v for a 

Then: v = a/8 (truncated) + c£P3AVBN) 

o s (a mod 8) *64 



7.3,1.28 PSDV8N 4 Rytes - Address of First Data Bucket 

This field contains the 32 bit V8N of the first 
data bucket in a Relative file. 



7.3.1.29 PSLMRN 4 Bytes - Maximum Record Number 

This field contains the user soecified maximum re- 
cord number which will be allowed on SPLIT ©Dera- 
tions to the Relative file organization. If the 
user specifies 0 then this field will contain the 
maximum record number possible (2**31-1), 



7.3.1.30 PSLEOF 4 Bytes - EOF V8N 

This field contains the last initialized (i,e,» 
zeroed) V8N (i,e«# the EOF VBN) for the Relative 
file organzat i on. 



'7.3.1.31 PSVERN 2 Bytes - Prologue Version Number 

This field contains a prologue version nubmer. 
The only legal value at thi 9 time is one (1), 



7.3.1.32 392 Bytes - Reserved for Future Use 



7.3.1.33 2 Bytes - Prologue Checksum (see 7.2) 
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7.3.1*34 Prologue Block 1 Layout - 



KSIVl 

KSDF3KS 

PSD8KS 



KSDTP 

KSNULL 

kskey 




i 



i Root Bucket 

) m m 

I Pointer 



Data Tyoe 1 


Flags 


"NULL" 


Character 1 


# of kev segments 


Key 


Of Ref. ■ |. 


Total Key Si ze 


Minimum Record Length 




Index Fill 


Quantity 




Data Fill 


Quantity 




Key Field 


Segment 



1 

| Offset Positions 

I 

! CKSPOS0-k$POS7) 

! 

! 



I i . - 

j Key Field Segment Sizes 

! (KSSIZ0-KSSIZ7) 



V5N For Next Kev 
Descriotor 

Offset To Next Key Desco, 



Root Level I Data Area U 

Data 8kts ! Index 9kts 

Size ! Size 






Kev Name String 
(32 Bytes) 



First Data Bucket 



KSNLV3 

K SNSYT 
K $ I A N 
K S D A N 
KSIBKS 

KSLVSN 

ksflgs 

PSFLGS 

KSNSEG 

■KSKYSZ 

KSHINL 

KSIFIL 

KSOFIL 

KSPOS 

KSSIZ 

K JKMM 
KSLDVB 
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Pointer 



/ Scare (14 Bytes) / 



p $ a y a x 



Max. Area # ! V 8 N Of 1st Area 

Start VBN of 1st Data Bucket 
(relative file only) 



Maximum Record 



IPSAVBN 

I 

I PSDV8N 



I pslhrn 



Number ! 

....................................... | 

Relative File EOF VBN I PILEOF 

mm m m ( 

(Last Initialized VBN - Zeroed) I 



I Prologue Version Number I PSVERN 

I—— — — ! 

! I 

/ Scare (392 Bytes) / 

! I 



B 1 ock Checksum I 

Byte Offset 510 ! 



7,3.2 Alternate Key Prologue Blocks - 

Alternate key_proloaue blocks are chained together through 
the KSNLVS field of the key descriptors (see Section 
7. 2, 1.1), Five alternate key descriptors can fit In a VBN, 



7.3.3 Area Descriptor Prologue Blocks - 

The Indexed. file organization reauires a methoa of allocat- 
ing the virtual blocks of the file to the various usages 
within the file (e.q,# Index buckets and Data buckets). The 
structure which allows this virtual block allocation manage- 
ment is the Area Descriptor, The Indexed file supports mul- 
tiple allocation areas to achieve the following user file 
design capabilities! 

1. Different bucket sizes between the Index buckets 
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and associated data buckets, 

2, Different index and data bucket sizes on a oer key 
basis, 

3. Allocation placement control for the various ele- 
ments of the file. 



Eight area descriptor can.be contained in a virtual block, 
and all the area descriptor prologue blocks are virtually 
contiguous (see Sections 7,2,1,26 and 7.2,1.27 for more de- 
tails). 



7.3.3, 1 Soare 1 3yte - 



7. 3. 3, 2 A k F l G 1 byte - Flags (not used) 



7. 3. 3. 3 ASA ID i Byte - Area Number (0 - 254) 

This byte contains the Area's number and Is. used 
as a redundancy .check since all area descriptors 
are located at a fixed relative position to the 
start of the Area Descriptor orologue blocks. 



7. 3. 3. 4 ASBKZ 1 Byte - Bucket Size for Area 

This field contains. the. areas's bucket size In 
blocks (1 -32) which is the granularity of allo- 
cation. 



7. 3. 3.5 ASVOL 2 Byte - Relative Volume Number 

This field contains the relative volume number for 
the last file extend for this area when placement 
control was reouested. 
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7. 3. 3. 6 ASAL.N 1 Byte- - E x t end A 1 1 oe at i on Alignment 

This field contains the allocation alignment used 
for the last file extend for this area. 

Legal values for this field are! 

0 placement control not reouested 

X5SCYL cylinder alignment (not imolemented) 

X8SL8N logical bloek alignment 

XBSVBN virtual block alignment 

XSSRFI allocate close to related file 

by FJD (not imolemented) 



7. 3. 3, 7 A $ A OP 1 8yte - Alignment Qetions 

This field contains o6t i on bits to aualify the 
A $ A L N field. Legal values are as follows! 

X8SHRD Alignment is absolute and fail if not 
available, (note? illegal for X8SVSN or 
X8SRFI al i gnment ) , 

X8SCTG Allocation i9 to be contiguous. 



7. 3. 3. 9 ASAVL 4 Sytes - Available (Returned) Buckets 

This f i el d cent a i ns . t he 32 bit VBN of the first 
available bucket in a chain (linked through the 
first 4 bytes of the bucket) of buckets. This 
chain of buckets would be the result. of returning 
buckets back to the area. The returning of buck- 
ets is not currently supoorted by RMS so that the 
only legal value for this field is zero ( 0 ). 



7, 3. 3. 9 A$CVB 4 Bytes - Start VBN for Current Extent 

This field contains t h e " 3 2 bit start VBN for the 
current extent, 'The current extent is the extent 
from which buckets will be allocated. 
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7.3,3, l 3 ASCNB 4 Bytes - Number of blocks in Current Extent 

This f i el d contai ns the number of blocks that were 
aUccated to this current extent. The combination 
of ASCV8 and ASCNB describes in virtual, block 
terms the result of the file extend operation for 
the current extent. 



7,3,3,11 ASNU-S 4 Bvtes - Number of blocks used 

This field contains the number of blocks that have 
been allocated from the current extent. 



7.3,3,12 A $ N v B 4 Bytes - Next VRN to Use 

This field contains the 32 bit V8N to use for the 
start V9N of the next bucket allocated from the 
current extent. 



7.3.3,13 a$nxt 4 Bvtes * Start VBN for Next Extent 

This field contains the 32 bit start VBN for the 
next extent. When the current extent is used up 
the next extent is made the current extent and the 
next extent descriotion is zeroed. The area can 
only be extended when the next extent description 
is zero. 



7.3.3.14 A 5 X 9 Y 4 Bytes - Number of blocks in Next Extent 

This field contains the number of blocks that were 
allocated to this next extent. Thie combination 
of ASNXT and ASX8Y . describes in virtual, block 
terms the result of the file extend operation for 
the next extent. 



7.3,3.15 A50EQ 2 Bvtes « Default Extend Quantity 

This field contains the user soecifiea default 
file extend Quantity to be used whenever the area 
is to be extended bv RHS, A value of i? means use 
the file's OEQ. However, in no case will less 
than one bucket size for this area be reauested. 




Files-11 On-Oisk Structure 



PAGE 83 



7.3.3. 16 

7.3.3. 17 

7.3.3.18 

7.3.3. IP 
7 . 3 . 3 . 2 $ 



Reserved 2 Bytes - 



ASLOC 8 Bytes - Start IBM cri Volume 

This field contains the start logical block number 
for the last extent performed for this area. 



A $ R F I 6 Bytes - Related File ID 

This field contain the FID of a related file for 
the X6SBFI allocation alignment ,CA$A|»N) (not im- 
plemented) 



Soares 12 Bytes - 



ASCPC 2 Bvtes - Checksum 

This field is a dummy field to pad out the area 
decriotor to 64 bytes. This also allows the stan- 
dard Files-11 checksum to be stored in the last 
word of the Area Descriptor Prologue block. 




Files 

7.3.3 

ASFLG 

ASBK7 

ASAOP 
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7. a Sequential File Format 

The RMS Sequential file is. compatible with the FCS Fixed and 
Variable length record files. Please refer to Section 6,2 
through 6.2.3, The RMS variable with Fix Control record 
format is a generalization of the Sequenced Varialbe Length 
Records of FCS (Section 6,2,3) in that the fixed control 
area (always 2 bytes for FCS) can be varied between 1 to 255 
bytes, 



7.5 Relative File Format 

The Relative file currently uses virtual block one (i) for 
its prologue# and starts its data buckets at virtual block 
2, Records are stored in fixed length cells within unfor- 
mated buckets (no overhead bytes in bucket) starting at bvte 
0 and eackeo end to end_(i,e,» byte aligned). The virtual 
blocks within the relative file must be initialized (zeroed) 
when they are allocated to the file to support deleted re- 
cord cont rol , 



7.5.1 Pel at 1 ve' F i 1 e Record Formats - 

Records are stored in fixed length cells. The first byte of 
each cell is a record control byte used to provide deleted 
record control. The following bits are defined; 

OCSDEL record has been deleted 
DCSREC record exists 

A value of 0 indicates the cell has never contained a re- 
cord. 

The relative file supports variable and variable with fixed 
control length record uo to the reauired user specified Max- 
imum Record Size (MRS), In these cases the record control 
bvte is followed with a two byte binary count of the bytes 
in the record (the count does not include itself). If the 
cell size does not evenly divide the bueket size then the 
remaining s’gacein the bucket is dead soace and the next re- 
cord in the file will be stored in the first cell of the 
next bucket. In other words records never scan bucket boun- 
dar 1 es. 




Files-lt On-Disk Structure PAGE 86 



7,5. 1.1 Fixed Length Records - 



I Ctrl ! data (mrs bytes) 1 



cell sizes MRS+i 



7.5. 1.2 Variable Length Records - 



I Ctrl 1 size ! data (size bytes) I ! 



cell size a MRS + 3 



7.5. 1.3 Variable with Fixed Control Records - 



! Ctrl I size I fixed I data (size-fixed Ctrl bytes) ! 



cell size a MRS+fixed Ctrl size+3 



7.6 Indexed File Fermat 

The Indexed File uses virtual, blocks 1* 2 and if necessary 
uo to and including 84 as a maximum for its prologue. The 
current implementation on the PDP-11 will result in a prolo- 
gue of the following forms: 
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index and data bucket space starts at: 

C CPSAMAX/8C truncated) ) +PSAVBN) 

Records are stored In formatted buckets (buckets have, overh- 
ead bytes) and are oacked end to end ( i , e, # byte aligned). 
The bucket format and , tfie various record formats are given 
in the following sections. 



7.6,1 Index Structure - 

The Index is structured as a balanced tree. The nodes in 
the tree are buckets# and the nodes are serially searched. 
The Index node contains index records as specified in Sec- 
tion 7.5.2, 1, 

The bucket size is constant for index nodes# but may be di f- 
ferent than the Data buckets. The Data buckets are all the 
same size. 

Each level of the index is horizontaly linked via the Next 
bucket pointers, The horizontal linking is circular with 
the last bucket (noted by 8CSLBK) pointing back to the first 
bucket. The Data,buckets for an Index may be viewed as the 
data level (set) of the index and are linked in the same 
manner as buckets in any other level of the Index, Figure 
7-2 shows the structure of the Index, 

The key val ue associ ated with index records (see Section 
7.5.2. 1) is the highest or highest possible key value in the 
bucket pointed to by the bucket pointer in the record. 

The basic search rule for an index search is to fellow the 
first path tor which the search key is eaual to or less than 
the key value stored in the index record. 



7.6. 1.1 Primary Kev Index Structure - 

The primary key index for a file "is structured as stated in 
Section 7,5.0 above where the data level is composed ot 
buckets which contain the User's data records. The data 
buckets may also eontain'FRV records. See Section 7,5,3 and 
7, 5. 2. 3 tor details on RPV records. 
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7.6. 1,2 Alternate Key Index Structure - 

An alternate key index for a file is structured as stated in 
Section 7,5.0 above where the data level is composed of 
buckets which contain pointer array records as specified in 
Section 7, 5 , 2,4, Therefore the indices within the Indexed 
Fi 1 e Organi zat ion have the same structure, where only the 
i ntereretat i on of the records within the data level of an 
index i s d i f f e rent . 



7.6.2 Record Reference Vector (RRV) - 

fiber a record is inserted in an Indexed. file the record is 
assigned a reference vector address and t h i 3 address is 
stored in the data record in the record pointer field (see 
Section 7, 5,2. 2), This address is the initial address of 
the record, itself, 'Whenever the record is moved the 
record's reference vector record is updated with its new ad- 
dress, The record, in turn, points back to its reference 
vector so that it can be updated if the record is moved 
again, The reference vector record is created when the re- 
cord is moved for the first time. Using this technioue the 
worst case indirection for a record is kept at one, and we 
can always find the record via its reference vector address. 

The record pointers used within the Indexed file organiza- 
tion, and the REA (Record's File Address) returned to the 
user in the RFA field of the RA.B are always the record's 
reference vector address. 

The space reaui red for RRV pointers in the data records of a 
file is reouired to insure RFA addressing and alternate 
keys. The RRV records are stored at the end of the data re- 
cords in the user data buckets. The use of RRV's and secon- 
dary indices is graphically shown in Figure 7-3, 



7.6.3 Bucket Format - 

The Indexed organi zat i on uses a format ted_ bucket as its pri- 
mary unit of seondary storage, A bucket is composed of some 
number of virtual blocks in the range of 1-32 and has a 
header starting at byte one of the bucket. 

The Bucket is composed of three logical areas, a Header 
area, a Record storage area and a Free space area. 

Each of these areas will be described in the sections that 
follow. 
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7.6.3. 1 Header Area - 

The bucket header area is composed of a PAS data 
section, a. bucket storage control section, and a 
structure link section. The size of the bucket 
header is 14 bytes CSSBHD), 



7.6.3. 1.1 8SCHK l Byte - Check Bvte 

This is a one byte check character, Whenever a 
bucket, is written the value in the check byte is 
changed and copied into the last byte of the buck- 
et. whenever a bucket is read the check byte is 
compared to the copy for eauality, 8y this tech- 
niaue hardware failures during transfer are de- 
tectable Ci.e., the BUS breaks etc,). 



7,6.3-. 1,2 BSTAA 1 Byte - This Allocation Area 

This field contains the allocation area number 
that this bucket was allocated from. 



7.6,3, 1,3 B5ADR 2 Bytes - Bucket Address Sample 

This is a sample of the bucket's start VBN ad- 
dress, and is composed of the low order 16 bits of 
that address. This field is written upon bucket 
formatting, and is checked whenever the bucket is 
read into main memory. 



7,6,3. 1,4 9 $ N B Y 2 Bytes - Next Available Byte 

This field contains the byte address relative to 
the start of the bucket of the first free byte in 
the Free Storage Area of ^the bucket. 



7,6.3, 1.5 BSNID 1 Byte - Next Available 10 

This field contains the 10 number to use for the 
next record olaced in the bucket. 
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7.6.3. 1,6 B$LID 1 Byte - Last Available ID 

This ■field contains the ID number of the last ID 
in the contiguous range of ID's soecified by the 
contents of BSNID and 6 SLID. When the contents of 
BSNID are greater than the contents of 3SLID or is 
zero then there is no "next" available ID, When 
tMs condition occurs the bucket is scanned to 
find the largest contiguous nanae of unused ID's 
and BSNID and 9SLID are updated to describe that 
nanqe/ 



7.6.3. 1,7 BSN8K a Bytes - Next Bucket Pointer 

This field contains the start V9n of the next 
bucket at this level of the index or data e a r t i - 
tion for the Indexed file organization. This oo» 
inter always points to a bucket of the same size. 



7.6.3, 1.8 8SLEV 1 Byte * Level Number for Bucket 

This field contains the level number relative to 
the data level for this bucket* in the index. The 
Data level buckets contain a 0* the lowest level 
buckets of the index contain a 1* the next level 
buckets going towards the root contain a 2 etc. 



NOTE 

"Data buckets" refer to the buckets which 
contain the data records associated with 
the index. For the Dnimary index these 
are the user data records* and for the al- 
ternate index these. are system data re- 
cords which contain an array of pointers 
to user data records. 



7.6.3. 1,9 BSBCB 1 Byte - Control Bits 

This is a bit encoded byte field and is used in 
the processing of a bucket. The f o 1 1 ow i ng b i t s 
are defined for the indexed file o rgan i zat i on ? 
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BCSLB* » last bueket In level 
9CSP0T - root bucket of Index 



7. 6, 3, 2 Record Storage Area - 

The record storage area starts at the first bvte 
after the bucket header area* and ends at the bvte 
address stored In BSNBY minus one. The reeord 
structures In buckets vary, with the use of the 
bucket. Section 7,5,2 specifies the various re- 
cord structures used. 



7. 6. 3. 3 Free Storage Area - 

The free storage area starts at the byte address 
stored In BSN8Y and up to the check byte eoov.ln 
the bucket. Any and all free storage statistics 
refer to this contiguous free storage area. 
However it is possible due to. "fast" record dele- 
tions to have "free" space within the record sto- 
rage area of the bucket. The reclaiming of this 
soace Is done on an as needed basis. 



7, 6,3, A S$8HD 14 Bytes - Size of Header Area 

This symbol represents the sl 2 e of the bucket 
header area. 



7, 6, 3, 5 Bucket Format Layout » 



] 

8$T A A 1 

i 


I This Area 


1 Cheek Byte 


* i 

I 8 $ C H K 

m i 


] 

! 

i 


Bucket Address Samole 


1 8$ ADR 

„ | 


i 


Next Avai 1 abl e Bvte 


! BSN0Y 

m ! 


6SLID 


Last ID 


! Next ID 


m i 

1 BSNIO 

• t 




Next Bucket Pointer 
(Start VBN) 


m 1 

! BSNBK 
! 

m i 


3SBCB 


BCB 


1 Level 


t 

1 8SLEV 
- ! ST8HD 
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I Record Storage 

! Area 



Free Space 
Area 



Check Byte Copy I 

- I 



! 



I cCBSNBY) 

I 

I 

I 

I 

f 

1 

* 



7. 6. a Record Structures - 

The following record structures apply to the Indexed file 
organ i zat i on, 

7. 6.4.1 Index bucket record - 



i Byte 



n Bvtes 



m Bytes 



IRCB contains Index Record Control Bits 

The following bits are defined in the IRCB byte* 

ICSKCP Compressed key value (not currently de- 
f i ned) , 

IC$£MP Pointer to empty bucket, 

PS is the pointer size as follows; 

0 a 2 byte bucket pointer 

1 s 3 byte bucket pointer 

2 s 4 byte bucket pointer 



j 

IRCB | PS 



Bucket ! 

Pointer I 

! 

mmmmmmmmmmrn » 



Key Value 
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3 a undefined 



7. 6. 4, 2 General Data Bucket Record - 



I 

DRCB 1 PS I 



ID 



! Record I 

! Poi nter | 

1 ' Size ! 



I I 

1 Data 1 

I I 



1 Byte 
1 Byte 

N Bytes Optional 



No Size If Fixed Length Data 
M Byte9 

M a Size or Fixed Length 



DPCB contains Data Record Control Bits 



The following bits are defined in the DRCB byte: 

DCSDEL . Record deleted* or pointer to deleted 
record. 



DCSRRV 

DCSNPS 

DCSXDL 



DCSNCP 



Record reference vector record. 

No Pointer size field present (Qualifies 
PS) 

Pointer to record for this key no larger 
appl i es SUPDATE changed the key, but re- 
cord exists: note JO will be zeroed on 

all systems starting with Release 1 on 
RSX-HM V3, 

Do not compress this deleted record. 



PS is the pointer size for the Record pointer as 
f ol 1 ows 5 



® s 3 byte record pointer 
1 a 4 byte record pointer 
2=5 byte record pointer 
3 s undefined 
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7. fe, 4. 3 RRV Records - 

Record Reference Vect'or (RRV) records are records which 
point to the record associated with the reference vector. 
They function as "forwarding addresses" for the actual re- 
cords when they are moved. 

The format is as follows! 



i ----------- , 

! PRCB | PS I 

! I 

! ID I 



I Record I 
I Pointer ! 



where the OCSRRV bit is set in the DRCB field. 



7. 6, 4, 4 Deleted RRV Records - 

The R°V record for a deleted record can be as small as the 
first two bytes of the RRV record. In this case the follow- 
ing DRCB bits are set? 

OCSRRV 
, DCSNPS 
OCSOEL 



7.6.4. 5 Secondary (or alternate) Index Data - Record CSIDR) 
for which duplicate keys are allowed - 

The data records associated with an alternate index are^ po- 
inter arrays to the users data records. The format of the 
record i s as fol 1 ows! 



1 

1 


DRCB 1 PS | 


1 


Byte 


* • " 

Data Record 1 

| » . 


ID ! 


1 


Byte 


1 

1 mi 


Duol 1 cate Count 1 


4 


Bytes (DCSWPSsG) 


1 * 

Overhead ! 


Size 1 


?. 


Bytes 


1 ! 
! 


key Val ue i 


M 


Bytes 
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Data 

on 

Record 





SIDR Record 


1 x 


Byte 


Poi nter 




P o i n t e r # 1 


1 




A r ray 


1 


SIDR Record 


1 Y 


Bytes 


recc rd 


1 — 
! 


Pointer *2 

t 


! 

« * 

1 

i 

1 




i 




• 

• 

SIDR Record 


f 

I 

■ 1 

1 l 


Bytes 




| ■ M 1 


D oi nter #K 


1 

R | 







Fields within the pointer array record; 



PS This field contains the size of the duplicate 

count Held as follows 

0=3 bytes 

I = a bytes **THIS IS THE ONLY VALUE USED** 

2=5 bytes 
3 = undefined 

DRCB Bits used for pointer array records 

NCSNPS If this bit is set then there is no du- 
plicate count field. This is used for 
all array cent i nuat i ons records*' since 
the count applies to the total array. 



7. 6, <4.6 Secondary (alternate) Index Data Record - No Dupli- 
cates - 

\ 

The data records associated with an alternate index for 
which duplicate key values are not allowed is shown in Sec- 
tion 7. 5, 2, 4 except that the duplicate count field is omit- 
ted CDCSNPSsl) and there is only one SIDR Record Pointer, 



NOTE 

When a record is deleted the No Duplicates SIDR re- 
cord is compressed .out of the secondary index's data 
bucket at the time of the delete. 
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7,6.#.7 SIDR Record Pointers « 

The format of the record pointers used in Secondary Index 
Data Records is as follows! 



Overhead I 


! DRC9 | PS 


• 

i l Byte 


Record ! 


1 Repond 


IN 3y tes 


Poi nter 1 

3-5 bytes 1 


! Po i nt e r 

1 


1 

1 

* 



DRC8 bits used for SIDR record raointerss 



DCSKDL Pointer has been deleted due to key 
change on a SUPDATE operation. In this 
case the ID portion of the record po- 
i nter will be zero. 

DCSOEL Record associated with this pointer has 
been deleted. 
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F 1 qu re 7*2 
Index Structure 



Ooot 



! 1 ! 
! ! K 1 . , K x I 



! » 
V ! 



! 

! ! 

VV 



! ! K ab . , 

! 1 1 
i * I 




Ki 



i 



I 

1 



i 

i 



>« ! 



V 




i 

t 



Kab I 



i 

» 

! 



V 



! ! {Kab ! I 

1 I • • • I d a t a I ! 



• • • • 




! K 4 ! 



! 

i 

i 

! 

» 

! 

V 



! K i ! 
{data! 
i I 



NOTES; 

All buckets in a level are 1 inked horizontally fro* left to 
riqht via next bucket oointers (see Section 7.5.1. t, 7), 
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CASE Is Record Has Never Moved 



.... Pointer In Secondary Index 
I Pointer Array 

i 

v 



DRCB ! PS I 



ID 



t Record Pointer ' 
I (RRVP) ! 






I 

I 




User Data Record 



I Data ! RRVP s Records Reference 

.................. Vector Pointer 

CASE cl Record Has H 0 ved 



.... Pointer In Secondary Index 
i Pointer Array 

j 

V 



I DRCB I PS l« 



10 



I Record Pointer !---- 

— - - ! 

1 



I 

i 

< 

v 



ORCS ! PS I 



ID I 



i Record Pointer i 
I (RRVP) ! 



- Record Reference 
I Vector 
i 

! 

I 

< 

i 

I 

( 

» 



» 

i 

I 

J 

I 

i 

I 

i 

I 

I 

t 



User Data Record 



Data I 



Figure 7-3 



RRV Usage 
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[End of 00S2.PM0] 




